On approximately 1/2/2004 12:19 AM, came the following characters from
the keyboard of Johan Lindstrom:
After upgrading from 0.0.558 -> 0.0.670, the right click-menu seems
broken in TGL. The right-click menu displays alright, but the event
handlers never receive any calls. The normal menus attached to a normal
window works fine.
Actually I just installed the 0.0.665 version and it seems it is already
broken in that version.
I briefly diffed 558 and 665 but couldn't find anything obvious.
I didn't use 558 very long, so I'm not sure of all its features in
detail... I hadn't learned all of them before switching to 665 when it
came out.
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.
I can, however, confirm that popup menus seem to work fine (for some
definitions of fine, at least) in 665 and 670, as I have a number of
applications that use them.
In comparing the code sequences between my working programs, and your
non-working test case, it finally hit me what the difference is....
First see the code differences, then some more discussion. I'm actually
not sure what changed between 558 and 665 such that the 558 version
works the way you have it coded, and I did no research into that (at
least not yet).
The following minimal example works in 0.0.558, but not in later versions:
#!/usr/local/bin/perl -w
use strict;
use Data::Dumper;
use lib "..";
use Win32::GUI;
my $mnuMain = Win32::GUI::MakeMenu(
"&File" => "mnuFile",
" > &New\tCtrl+N" => "mnuFileNew",
);
my $winMain = new Win32::GUI::DialogBox(
-left => 700,
-top => 50,
-width => 300,
-height => 100,
-name => "winMain",
-text => "",
-menu => $mnuMain,
);
my $btnMenu = $winMain->AddButton(
-name => "btnMenu",
-text => "Popup Menu",
-left => 10,
-top => 10,
-height => 20,
-width => 100,
);
my $mnuPopup; # define this here, globally
$winMain->Show();
Win32::GUI::Dialog();
sub ::mnuFileNew_Click {
print "New selected\n";
return(1);
}
sub ::btnMenu_Click {
print "Popup menu\n";
# my # take out this "my"
$mnuPopup = Win32::GUI::MakeMenu(
"popup" => "popup",
" > &Left" => "mnuEditAlignLeft",
);
$winMain->TrackPopupMenu($mnuPopup->{popup},
$winMain->Left + $btnMenu->Left + 20,
$winMain->Top + $btnMenu->Top + 20,
);
return(1);
}
sub ::mnuEditAlignLeft_Click {
print "align left selected\n";
return(1);
}
__END__
Is this not the way to do popup-menus? Are there any examples working
with 0.0.670 I could try instead of my approach?
With the above changes, your sample code now works on 665 and 670.
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), 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 wiped out by the more dynamic ones, and then they would quit
working, probably by starting to invoke menu entries from the more
dynamic menu that wiped them out. Not good.
The design of the menus (which I just figured out this last week,
actually) is clearly aimed at having menus that are defined once, mostly
statically. It is fine to use Change to alter the entries, it is less
fine to dynamically define and then discard entries, I think that not
all data in the Win32::GUI global structures (like %Menus) are returned
when a menu item is destructed.
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 menu data stays around long enough to be found and
used. But reuse of the menu probably leaks resources through
redefinition of the menu.
So this response has
(1) demonstrated a workaround for your problem in the current sample code,
(2) discussed a possible resource leak ($MenuIdCounter values, and
possibly %Menus entries which would be a real memory leak) in
Win32::GUI, which only occurs if menus are "too dynamic",
(3) discussed how to avoid dynamically creating menus by creating them
globally, once, and using Change to alter their content,
(4) left open why 558 works with the original sample code
(5) left open any discussion about cures to 665 and/or 670 that would
resolve the resource leaks... for the present, it seemed simpler to me
(and would run faster) to make the menus as static as possible, and code
the application for that, rather than to learn enough more about XS and
Win32::GUI at the present time to fix the resource leaks so that dynamic
menus can be leakproof, and used with impunity.
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.
* reading code *
- The %Win32::GUI::Menus hash, should the value really be the menu
object? Should it not be the handle? the XS function GetMenuFromID
indicates that. But MenuItem::new and MenuButton::new assigns $self as
the value if -name is passed, which it is when called from the sub
MakeMenu(). Is that really right?
I tried fixing it in the Perl code, but it didn't help so maybe I'm just
not thinking straight... and now I have to go to work :)
/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
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
