Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Menu frustration...

96 views
Skip to first unread message

Bill Waddington

unread,
Sep 29, 2018, 10:59:45 AM9/29/18
to
Hey all,

8 years ago I took my first crack at a GUI program: a Sudoku solver.
With some kind help here I actually got that one up and running.

Now working on a Japanese/English quiz thing and totally flummoxed by
what should be simple - trivial perhaps. Missing the obvious...

I'm finally able to build a simple menu that includes a
"config/options" cascading menu of checkbuttons. The intent is that
one _or more_ can be turned off or on at each access.

The problems: toggling any single one causes the menu to unpost (if
that's the right word...) and while a checked item will show a tick
mark when accesses again - there's no check box to make it obvious to
the user what the intent is.

I'd expect these (no unpost, visible box) to be options (or
defaults...) but no joy. Apart from using a command to repost the
thing, is there a way to keep it visible until a "done" button is
pressed?

I can build a config widget by hand but am having a devil of a time
getting it to show up where I want it - but that's a conversation for
another thread.

Many thanks - and apologies for not having the vocabulary to ask a
proper question.

Bill
--
William D Waddington

"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

Christian Gollwitzer

unread,
Sep 29, 2018, 11:11:30 AM9/29/18
to
Am 29.09.18 um 16:59 schrieb Bill Waddington:
> I'm finally able to build a simple menu that includes a
> "config/options" cascading menu of checkbuttons. The intent is that
> one _or more_ can be turned off or on at each access.
>
> The problems: toggling any single one causes the menu to unpost (if
> that's the right word...) and while a checked item will show a tick
> mark when accesses again - there's no check box to make it obvious to
> the user what the intent is.

Are you sure that a menu is the right thing for your use case? IMHO a
list of checkboxes would be more appropriate.

It might be tedious to create those, but fortunately there are some
tools to make it easier. First, you can create them in a loop from a
simple list of options, like this:

package require Tk
toplevel .parent
foreach {var description} {
japanese "Write japanese text"
hinting "Show hints"
} {
ttk::checkbutton .parent.$var -variable ::$var -text $description
grid .parent.$var -sticky nsew
}

...it should be obvious how to extend this.


Then there are packages like "gridplus" or "tablelist", which can make
these things even easier easier.

Christian

Bill Waddington

unread,
Sep 29, 2018, 11:18:58 AM9/29/18
to
Thanks! I'll study your suggestion. Initially I did build a list of
checkboxes but had such a struggle getting it to show where I wanted I
tried the menu approach instead.

Perhaps switching to the grid manager will make things easier ... but
one more thing to learn...

I very much appreciate the help!

onem...@gmail.com

unread,
Sep 29, 2018, 6:04:42 PM9/29/18
to
If you're trying to put together a typical menubar menu, you may want to look at this menu shorthand proc:
http://wiki.tcl.tk/16327

I took the idea from there and ran with it in my own projects; I've updated the page with my latest tweaks. It does checkbuttons, radio buttons, submenus, and separators; the pattern should be easy to extend to other menu constructs. And it's SO much easier to read in the top-level code.

--Erik

Bill Waddington

unread,
Sep 30, 2018, 8:23:50 PM9/30/18
to
On Sat, 29 Sep 2018 17:11:27 +0200, Christian Gollwitzer
<auri...@gmx.de> wrote:

>Am 29.09.18 um 16:59 schrieb Bill Waddington:
>> I'm finally able to build a simple menu that includes a
>> "config/options" cascading menu of checkbuttons.
...
>Are you sure that a menu is the right thing for your use case? IMHO a
>list of checkboxes would be more appropriate.
...

OK, I've officially lost my mind...

I managed to hand-build the equivalent of a menu bar with selections
that pop up message windows: "help", "about", etc... (Haven't set up
the checkbox thing yet.) They seem to work OK.

Since the app itself is small - not full screen - I use toplevel to
make the pop-ups since the text in them may need a window larger than
the main app window - and I could never figure out how to get the
whole thing to resize when I popped up a window. Getting the geometry
of the top-level window and using it in my pop-ups lets me post them
over the top of the app with a bit of offset, and it looks pretty
good.

Here's where it gets weird: I also use the same pop-up proc to bring
up an error window if some files I need are missing. That works too -
but the fool error window pops up offset from my display's corner, not
the app's main window... and it pops up BEHIND the main window.

Doesn't matter what order I do things in, what kind of delays I (try
to) introduce, or any of the other lame tricks I've tried.

I can actually see the main window getting drawn (or finished drawing)
AFTER the error pop-up even though the program order is main GUI drawn
first, files checked later.

If I invoke the file check manually by assigning it to one of my menu
buttons, then the error windos pops up where I want it. That isn't a
reasonable thing to do in this situation, though.

So... is the completion of grid operations really asynchronous? Any
sane way to sync it and wait for completion before my code moves on?

lost here...

Bill Waddington

unread,
Sep 30, 2018, 8:41:20 PM9/30/18
to
A screen grab illustrating my frustration:

http://www.beezmo.com/geezblog/?p=1842

Really sorry to be such a pest. I'm obviously working above my pay
grade :(

Rich

unread,
Sep 30, 2018, 8:52:49 PM9/30/18
to
Bill Waddington <william.w...@beezmo.com> wrote:
> So... is the completion of grid operations really asynchronous?

The processing of *all* Tk GUI operations are asynchronous.

> Any sane way to sync it and wait for completion before my code moves
> on?

Yes, see these commands:

1) 'tkwait' command
2) the 'update' command
3) using 'bind' to schedule code to run when a <Configure> event is
sent to a window

in their respective man pages.

But, also see http://wiki.tcl.tk/1255 (Update considered harmful)

Rich

unread,
Sep 30, 2018, 8:56:12 PM9/30/18
to
Bill Waddington <william.w...@beezmo.com> wrote:
> A screen grab illustrating my frustration:
>
> http://www.beezmo.com/geezblog/?p=1842
>
> Really sorry to be such a pest. I'm obviously working above my pay
> grade :(

Are you running on Windows? (I see "Command Prompt" there in the
desktop, implying Windows).

Is it W10?

If yes, then you might also be fighting W10's oddball desire to
position windows that it thinks are popups underneath other windows
instead of on top.

I've lost count of how many times I've had to go hunting for a
"save-as" dialog that W10 has decided should "open" *underneath* other
windows when I try to do a save as on my work machine.

Christian Gollwitzer

unread,
Oct 1, 2018, 3:04:05 AM10/1/18
to
Am 01.10.18 um 02:52 schrieb Rich:
> Bill Waddington <william.w...@beezmo.com> wrote:
>> So... is the completion of grid operations really asynchronous?
>
> The processing of *all* Tk GUI operations are asynchronous.
>
>> Any sane way to sync it and wait for completion before my code moves
>> on?
>
> Yes, see these commands:
>
> 1) 'tkwait' command
> 2) the 'update' command
> 3) using 'bind' to schedule code to run when a <Configure> event is
> sent to a window


In addition, "wm transient" https://wiki.tcl.tk/3542
It informs the window manager, that the toplevel is a dialog/popup
belonging to the main window. This might already make the problem go away.

Christian

Bill Waddington

unread,
Oct 1, 2018, 10:30:59 AM10/1/18
to
Thanks! That helps. The geometry (location) is still wrong but at
least it isn't a "pop-behind", and looks like it will always be
visible even if not quite where I want it.

I think I can restructure things to not even build the main GUI and
not use geometry in the error case, which will probably make more
sense to the use. I can still use a common message proc to keep thing
a bit cleaner.

thanks all,

Bill Waddington

unread,
Oct 8, 2018, 12:16:40 PM10/8/18
to
On Sat, 29 Sep 2018 07:59:38 -0700, Bill Waddington
<william.w...@beezmo.com> wrote:

>Hey all,
> ...
>Now working on a Japanese/English quiz thing and totally flummoxed by
>what should be simple - trivial perhaps. Missing the obvious...
>...

Thanks to the kind help here and in the character encoding thread I've
got something up and running :)

http://www.beezmo.com/geezblog/?p=1842

Non-tcl-idiomatic code, looks like fortran, ... whitespace and
indentation abuse...

Anyone have a tcl code beautifier? I've seen reference to Frink - good
and bad - but the download links I can find don't seem to work.

thanks again for the help - this group rocks,
0 new messages