At 18:06 2004-01-02, Glenn Linderman wrote:
In the above description you mention "right click-menu" But none of your
example code attempts to capture the "_RightClick" event. So I'm not
quite sure what you are asking.
The button was just the easiest way to get a minimal test case, since the
menu itself came out fine I didn't figure that would make any difference.
Modulo the confusion :)
With your fix it works fine. Thanks!
Any reports of other applications that broke popup-menus? Any ideas from
the developers?
There are two problems with defining locally scoped menus: one, is that
they are gone before they can be used (not sure what 558 did differently
to make that work),
This is kind of weird. I didn't go for the global var, in my test case I
stuck it in a hash to keep it in scope. But IIRC, that's exactly what the
%Win32::GUI::Menus hash is for. Huh?
Another thing I just tried was this:
$winMain->TrackPopupMenu($mnuPopup->{popup},
$winMain->Left + $btnMenu->Left + 20,
$winMain->Top + $btnMenu->Top + 20,
);
print "TRACKED\n";
Win32::GUI::DoEvents();
print "Done events\n";
This prints:
TRACKED
align left selected
Done events
which means the WM_COMMAND is put in the message queue and then I force it
to be handled before the menu goes out of scope. Without the DoEvents(),
the menu goes out of scope, and the WM_COMMAND is processed in the next
message loop with no menu to be found.
Well, at least it's interesting :)
and the second is that it consumes $MenuIdCounter values which never get
returned. Now that is a "big" number (for some definitions of "big"),
but even so, if a program repeatedly defines and destroys menus, and
loops on that long enough, it will "run out" and the counter will
"overflow" and "wrap around", and get back to reusing numbers that may be
in use for less dynamic menus, and things could get confused. I think
the effect would be that the less dynamic menus would get
I think, with the code not-so-fresh in my mind, that if it really wraps,
the Win32::GUI::Menus hash will be overwritten with the new menu handles,
so that will work out fine. Not that it will wrap (isn't it a long?)
By putting your menu definition inside another _Click routine (and I
didn't fix that, above, but moving it all up where the $mnuPopup variable
is now declared would do so) you are effectively dynamically defining the
menu just before popping it up. Now that the variable is more global, the
Which I have to do, since they are truly context sensitive. And I'm willing
to live with the minor resource waste.
I'm pretty sure your remarks below are just the result of confusion. The
menus themselves function fine with the current internal data structures,
within the limits of the dynamics discussed above.
Yep. Thanks again for the help!
A new release of TGL is to be expected soonish.
/J
-------- ------ ---- --- -- -- -- - - - - -
Johan Lindström Sourcerer @ Boss Casinos [EMAIL PROTECTED]
Latest bookmark: "Assembly Language Windows Applications"
http://grc.com/smgassembly.htm
dmoz (1 of 3): /Computers/Programming/Languages/Assembly/ 66
