Place and Place Forget

[Frank Goenninger DG1SBG]

Hi all:

Suppose I have a button btn1 that I placed with place. This button is
then made invisible with

place forget .w.btn1

Works fine. But how do I make this button visible again? I wanted to
do a simple

place .w.btn1

but Tcl/Tk says:

wrong # args: should be "place option|pathName args"

Hm? Should I destroy the button and re-create it each time I want it
to become visible/unvisible ?? Not really, or?

Thx for any help.

Frank

[Bruce Hartweg]

you don't need to destroy the widget, but you do need to tell place
the options on *where* to place it (same as you did the initial time).
if the code soing this doesn' "know" or want to "know" (in a hardcoded
sense) about initial placeing options (e.g. a proc that handle
hiding/showing different widgets) then before doing the place forget
use [place info ...] to get he config options, and save them off
for using when trying to place the3 widget back.

optionally, redo your layou using the grid geometry manager
and the utilize the "grid remove" command which unmaps the widget
but remembers the configuration so simply doing a "grid $w" will
put it back right where it was.

Bruce

[Gerald W. Lester]

BTW, it is considered a better GUI design to not remove and add components
but rather to change its state between disabled and normal.

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

[Frank Goenninger DG1SBG]

Bruce Hartweg <doNO...@nowhere.com> writes:

> Frank Goenninger DG1SBG wrote:

>> Hm? Should I destroy the button and re-create it each time I want
>> it
>> to become visible/unvisible ?? Not really, or?
>>
>
> you don't need to destroy the widget, but you do need to tell place
> the options on *where* to place it (same as you did the initial time).
> if the code soing this doesn' "know" or want to "know" (in a hardcoded
> sense) about initial placeing options (e.g. a proc that handle
> hiding/showing different widgets) then before doing the place forget
> use [place info ...] to get he config options, and save them off
> for using when trying to place the3 widget back.

Thanks, Bruce - this works.

[Uwe Klein]

you can play around with other methods
if you put a window sized frame first like:
frame .w.spanishwall ...-widht $like.w -height $like.w
place .w.spanishwall 0 0 ...
place .w.button ...
# then try

lower .w.button
raise .w.button

uwe, DG5AO

[Frank Goenninger DG1SBG]

"Gerald W. Lester" <Gerald...@cox.net> writes:

> BTW, it is considered a better GUI design to not remove and add
> components but rather to change its state between disabled and normal.

Hm, no. I don't agree. IMO it is considered best practice to only
present information to the user she actually needs - that especially
true for inexperienced users (kids, people with no or little computer
knowledge).

But, yeah, thanks for a comment on a question I haven't even asked.

;-)

Frank

[Frank Goenninger DG1SBG]

Uwe Klein <uwe_klein_...@t-online.de> writes:

> you can play around with other methods
> if you put a window sized frame first like:
> frame .w.spanishwall ...-widht $like.w -height $like.w
> place .w.spanishwall 0 0 ...
> place .w.button ...
> # then try
>
> lower .w.button
> raise .w.button
>
>
> uwe, DG5AO

Thanks, Uwe - I like your naming scheme - kinda verbose ;-)

73, Frank DG1SBG

[Bryan Oakley]

As with all things GUI, "it depends". There are certainly cases for both
modes of operation. For example, firefox's use of a popup find widget at
the bottom of the GUI is a Good Thing IMHO. When I need extra space I
can turn it off, and when I want to do a find it springs into existence.

The problem lies in the definition of "information ... she actually
needs". One could argue someone needs to see all options, even those
that are disabled, to know what is possible under some circumstances.

As a counter example, if you had a tool to play back some type of data,
you wouldn't want to totally hide the "stop" button until the user
presses "play". It is important to have both visible even if they can
only interact with one or the other at any one time.

Bottom line: both hiding and presenting-but-disabling are equally valid.
It all depends on the specifics of application, the target audience, and
the problem they are trying to solve.