From: Johan L. <jo...@ba...> - 2004-01-05 02:08:20
|
When I first looked at Win32::GUI for the first time many many years ago=20 (4? ok, not so many) I found it kind of confusing how the objects and=20 events worked. Coming from an OO background and with experience from a few other window=20 toolkits (VB and Borland TurboVision among others) I would have expected = to=20 subclass the Window class, create an object, add controls to the object,=20 and then I would defined methods in my subclass to be called when events=20 fired. Kind of like this: package DemoWindow; #My DemoWindow is-a Window... use base qw(Win32::GUI::Window); #...but with event handlers for events that may fire sub btnOk_Click { my $self =3D shift; #the Window object #Change text of the clicked button $self->btnOk->Text( "Ok - " . int(rand(100)) ); return(1); } But that's not how it works. Instead, event handlers based on the -name o= f=20 the windows and controls created. They are sub routines called in a=20 procedural fashion which requires me as an application programmer to keep= =20 track of which window the event belongs to. This is not very convenient. I have not yet seen any "best practice" emerge for dealing with this.=20 Either the window variable needs to be a global or a singleton (which in=20 this case is the same thing, but without the stigma of globals, and peopl= e=20 don't argue back when you bring up the havey artillery of design patterns= ),=20 or it has to be connected to a global or singleton which is your=20 "application" object or whaterver. It's nothing that can't be solved, but= =20 it's either inconvenient or not very maintainable. One other drawback with the event-handler-as-procedure approach is that=20 there can only be one instance of the window, because if you create a new= =20 window with the exact same names the event handler sub has no way to=20 determine which window fired the event. This can be coded around at great= =20 inconvenience (with Perl, few things are impossible). My point is: If only the Window object (or the window object of the=20 control) firing off the event was passed as the first parameter to the=20 event handler everything would be so much easier to live with. Finding th= e=20 event handler sub in the correct package (OO style) would be a boon. Actually, the result of my holiday hacking today is a module that pretty=20 much does this. Win32::GUI::Window::Object http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/ The synopsis script (below) creates three distinct windows of the same=20 class DemoWindow. The event handlers are methods on a subclass of=20 Win32::GUI::Window, so the context ($self) for all events is the current=20 Window::GUI::Window object. Consider this a proof-of-concept. A test of whether it could be done or=20 not. I've had the idea for a long time, but never had the free time and=20 motivation to actually do it. I have obviously not done anything real wit= h=20 this yet :) - Is this something that seems useful to proceed with? At least the=20 concepts, if not the code? - Is this something that can easily be solved from within Win32::GUI XS=20 code, passing the window object as the first variable ot the event=20 handlers? Perhaps using Perl's OO mechanism so that the correct package i= s=20 used? Doing it the real way is definitely more stable than my hack. - The subclassing isn't necessary, but could be useful. At the moment, wi= th=20 the objects as hash keys in the object, there is a high risk of clobberin= g=20 them unintentionally, should people start subclassing Win32::GUI::Window = en=20 masse. Perhaps they could be moved to a "_controls" hash ref property of=20 the window or something? Would that be difficult to use from XS code? So finally, an example program using Yet Another Event Model: http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/synopsis.pl.txt #!/usr/local/bin/perl -w use strict; use Data::Dumper; use Win32::GUI; use lib ("../lib"); use Win32::GUI::Window::Object; for (1..3) { my $id =3D int(rand(100)); my $win =3D DemoWindow->winCreate($id); $win->Show(); } Win32::GUI::Dialog(); package DemoWindow; #Inherit from the new Window-as-object class use base qw(Win32::GUI::Window::Object); #A demo property to give it some identity use Class::MethodMaker get_set =3D> [ "no" ]; #Class method to create/build a window of this class. It #could eventually be a window built by TGL. # #This could be in the new() method as well, calling the #SUPER::new() to create the object, then setting the no() #property. # sub winCreate { my $pkg =3D shift; my ($no) =3D @_; my $self =3D $pkg->new( -left =3D> 100 + int(rand(400)), -top =3D> 50 + int(rand(200)), -width =3D> 300, -height =3D> 100, -name =3D> "winMain", -text =3D> "Window $no", ); $self->no($no); #Set the demo property my $btnHelloWorld =3D $self->AddButton( -name =3D> "btnHelloWorld", -text =3D> "Hello world!", -left =3D> 10, -top =3D> 10, -height =3D> 20, -width =3D> 100, ); return($self); } #Event handlers are ordinary methods, with $self as #the first parameter as usual. This gives context to the #event, making it possible to have many instances of the #same window class. sub winMain_Terminate { my $self =3D shift; print "winMain_Terminate from DemoWindow with no (" . $self->no . ")\n"; return(-1); } sub btnHelloWorld_Click { my $self =3D shift; my $no =3D $self->no(); print "btnHelloWorld_Click in DemoWindow no =3D=3D $no\n"; $self->Text("Window $no - " . int(rand(100)) ); return(1); } __END__ /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindstr=F6m Sourcerer @ Boss Casinos jo...@ba... Latest bookmark: "ACM Queue - Code Spelunking Exploring Cavernous..." <http://www.acmqueue.com/modules.php?name=3DContent&pa=3Dshowpage&pid=3D6= 7&page=3D7> dmoz (1 of 4): /Arts/Music/Bands_and_Artists/T/ 20 |
From: Glenn L. <pe...@ne...> - 2004-01-05 04:40:47
|
Johan, That is an interesting idea, and of course, makes things more OO-like. OO-likeness, in my opinion, doesn't necessarily make something better, but in this case there are a couple benefits that you point out: the ability to have multiple instances of a Window or widget without name conflicts, and confusion between the window object variable and its name. The latter can be "worked around" with naming conventions, of course, but the former requires either code duplication, or, well, something like your new module, which is quite a bit of work. What I can't tell by glancing at your module is whether you can deal with existing windows using your module. One thing that works today with Win32::GUI is that you can "take over" an existing Window, and perform operations on it using the Win32::GUI methods. Does this still work with your class? I don't know why it wouldn't, but then again, I didn't try to prove that it would. Your comments on that topic would be welcome. Another orthogonal issue is the New Event Model. If it were finished and working. NEM allows the event subs to be nameless. Of course, there is still the problem of trying to support multiple instances of a Window or widget. It is not clear, though, how your approach would integrate into the NEM. Maybe that doesn't matter, except perhaps to people that use it. I tried the NEM, but found too many bugs and missing features. But it appears some people are using it. None of my current Win32::GUI applications would currently benefit from being able to have multiple instances of the same sort window, but I can certainly envision some applications that I might want to write that could benefit. So that is why I find it an interesting idea. I imagine that it would be quite simple to add an additional parameter to the event calls, which would be the window object, as the XS code does have pointers to sufficient information. Whether that would have a significant impact on performance, I do not know, but probably there would be less impact than the approach you have taken in your pure Perl proof of concept. Certainly it would be less code generated for an application if done in XS, but also harder to maintain code, probably. Not sure it would be much harder, though, but XS is more complex than Perl. Well, there's some initial comments for you to ponder. Not clear that I'll have the time or need to play with this at the moment, but maybe someone will. On approximately 1/4/2004 6:07 PM, came the following characters from the keyboard of Johan Lindstrom: > When I first looked at Win32::GUI for the first time many many years ago > (4? ok, not so many) I found it kind of confusing how the objects and > events worked. > > Coming from an OO background and with experience from a few other window > toolkits (VB and Borland TurboVision among others) I would have expected > to subclass the Window class, create an object, add controls to the > object, and then I would defined methods in my subclass to be called > when events fired. Kind of like this: > > > package DemoWindow; > #My DemoWindow is-a Window... > use base qw(Win32::GUI::Window); > > #...but with event handlers for events that may fire > sub btnOk_Click { my $self = shift; #the Window object > #Change text of the clicked button > $self->btnOk->Text( "Ok - " . int(rand(100)) ); > return(1); > } > > > But that's not how it works. Instead, event handlers based on the -name > of the windows and controls created. They are sub routines called in a > procedural fashion which requires me as an application programmer to > keep track of which window the event belongs to. This is not very > convenient. > > I have not yet seen any "best practice" emerge for dealing with this. > Either the window variable needs to be a global or a singleton (which in > this case is the same thing, but without the stigma of globals, and > people don't argue back when you bring up the havey artillery of design > patterns), or it has to be connected to a global or singleton which is > your "application" object or whaterver. It's nothing that can't be > solved, but it's either inconvenient or not very maintainable. > > One other drawback with the event-handler-as-procedure approach is that > there can only be one instance of the window, because if you create a > new window with the exact same names the event handler sub has no way to > determine which window fired the event. This can be coded around at > great inconvenience (with Perl, few things are impossible). > > My point is: If only the Window object (or the window object of the > control) firing off the event was passed as the first parameter to the > event handler everything would be so much easier to live with. Finding > the event handler sub in the correct package (OO style) would be a boon. > > > Actually, the result of my holiday hacking today is a module that pretty > much does this. Win32::GUI::Window::Object > http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/ > > The synopsis script (below) creates three distinct windows of the same > class DemoWindow. The event handlers are methods on a subclass of > Win32::GUI::Window, so the context ($self) for all events is the current > Window::GUI::Window object. > > Consider this a proof-of-concept. A test of whether it could be done or > not. I've had the idea for a long time, but never had the free time and > motivation to actually do it. I have obviously not done anything real > with this yet :) > > > - Is this something that seems useful to proceed with? At least the > concepts, if not the code? > > - Is this something that can easily be solved from within Win32::GUI XS > code, passing the window object as the first variable ot the event > handlers? Perhaps using Perl's OO mechanism so that the correct package > is used? Doing it the real way is definitely more stable than my hack. > > - The subclassing isn't necessary, but could be useful. At the moment, > with the objects as hash keys in the object, there is a high risk of > clobbering them unintentionally, should people start subclassing > Win32::GUI::Window en masse. Perhaps they could be moved to a > "_controls" hash ref property of the window or something? Would that be > difficult to use from XS code? > > > > So finally, an example program using Yet Another Event Model: > http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/synopsis.pl.txt > > #!/usr/local/bin/perl -w > > use strict; > use Data::Dumper; > use Win32::GUI; > use lib ("../lib"); > use Win32::GUI::Window::Object; > > > > for (1..3) { > my $id = int(rand(100)); > my $win = DemoWindow->winCreate($id); > $win->Show(); > } > > Win32::GUI::Dialog(); > > > > > > package DemoWindow; > > #Inherit from the new Window-as-object class > use base qw(Win32::GUI::Window::Object); > > > > #A demo property to give it some identity > use Class::MethodMaker get_set => [ "no" ]; > > > > #Class method to create/build a window of this class. It > #could eventually be a window built by TGL. > # > #This could be in the new() method as well, calling the > #SUPER::new() to create the object, then setting the no() > #property. > # > sub winCreate { my $pkg = shift; > my ($no) = @_; > > my $self = $pkg->new( > -left => 100 + int(rand(400)), > -top => 50 + int(rand(200)), > -width => 300, > -height => 100, > -name => "winMain", > -text => "Window $no", > ); > > $self->no($no); #Set the demo property > > my $btnHelloWorld = $self->AddButton( > -name => "btnHelloWorld", > -text => "Hello world!", > -left => 10, > -top => 10, > -height => 20, > -width => 100, > ); > > return($self); > } > > > > #Event handlers are ordinary methods, with $self as > #the first parameter as usual. This gives context to the > #event, making it possible to have many instances of the > #same window class. > > sub winMain_Terminate { my $self = shift; > print "winMain_Terminate from DemoWindow with no (" . $self->no . > ")\n"; > return(-1); > } > > > > sub btnHelloWorld_Click { my $self = shift; > my $no = $self->no(); > print "btnHelloWorld_Click in DemoWindow no == $no\n"; > $self->Text("Window $no - " . int(rand(100)) ); > > return(1); > } > > > > __END__ > > > /J > -------- ------ ---- --- -- -- -- - - - - - > Johan Lindström Sourcerer @ Boss Casinos jo...@ba... > > Latest bookmark: "ACM Queue - Code Spelunking Exploring Cavernous..." > <http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=67&page=7> > > dmoz (1 of 4): /Arts/Music/Bands_and_Artists/T/ 20 > > > > ------------------------------------------------------- > 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 > Per...@li... > 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. |
From: Glenn L. <pe...@ne...> - 2004-01-05 04:55:53
|
On approximately 1/4/2004 8:41 PM, came the following characters from the keyboard of Glenn Linderman: > Johan, > > That is an interesting idea, and of course, makes things more OO-like. > OO-likeness, in my opinion, doesn't necessarily make something better, > but in this case there are a couple benefits that you point out: the > ability to have multiple instances of a Window or widget without name > conflicts, and confusion between the window object variable and its > name. The latter can be "worked around" with naming conventions, of > course, but the former requires either code duplication, or, well, > something like your new module, which is quite a bit of work. Oh, and the multiple instances issue can be worked around solely by adding the extra parameter of window object pointer to the event subroutines... if done internally to Win32::GUI, it wouldn't need to be OO-like to solve the multiple instances problem. > What I can't tell by glancing at your module is whether you can deal > with existing windows using your module. One thing that works today > with Win32::GUI is that you can "take over" an existing Window, and > perform operations on it using the Win32::GUI methods. Does this still > work with your class? I don't know why it wouldn't, but then again, I > didn't try to prove that it would. Your comments on that topic would be > welcome. > > Another orthogonal issue is the New Event Model. If it were finished > and working. NEM allows the event subs to be nameless. Of course, > there is still the problem of trying to support multiple instances of a > Window or widget. It is not clear, though, how your approach would > integrate into the NEM. Maybe that doesn't matter, except perhaps to > people that use it. I tried the NEM, but found too many bugs and > missing features. But it appears some people are using it. Yet another orthogonal issue is whatever enhancements or newer models Aldo might be working on for the next major version of Win32::GUI. > None of my current Win32::GUI applications would currently benefit from > being able to have multiple instances of the same sort window, but I can > certainly envision some applications that I might want to write that > could benefit. So that is why I find it an interesting idea. > > I imagine that it would be quite simple to add an additional parameter > to the event calls, which would be the window object, as the XS code > does have pointers to sufficient information. Whether that would have a > significant impact on performance, I do not know, but probably there > would be less impact than the approach you have taken in your pure Perl > proof of concept. Certainly it would be less code generated for an > application if done in XS, but also harder to maintain code, probably. > Not sure it would be much harder, though, but XS is more complex than Perl. > > Well, there's some initial comments for you to ponder. Not clear that > I'll have the time or need to play with this at the moment, but maybe > someone will. > > > On approximately 1/4/2004 6:07 PM, came the following characters from > the keyboard of Johan Lindstrom: > >> When I first looked at Win32::GUI for the first time many many years >> ago (4? ok, not so many) I found it kind of confusing how the objects >> and events worked. >> >> Coming from an OO background and with experience from a few other >> window toolkits (VB and Borland TurboVision among others) I would have >> expected to subclass the Window class, create an object, add controls >> to the object, and then I would defined methods in my subclass to be >> called when events fired. Kind of like this: >> >> >> package DemoWindow; >> #My DemoWindow is-a Window... >> use base qw(Win32::GUI::Window); >> >> #...but with event handlers for events that may fire >> sub btnOk_Click { my $self = shift; #the Window object >> #Change text of the clicked button >> $self->btnOk->Text( "Ok - " . int(rand(100)) ); >> return(1); >> } >> >> >> But that's not how it works. Instead, event handlers based on the >> -name of the windows and controls created. They are sub routines >> called in a procedural fashion which requires me as an application >> programmer to keep track of which window the event belongs to. This is >> not very convenient. >> >> I have not yet seen any "best practice" emerge for dealing with this. >> Either the window variable needs to be a global or a singleton (which >> in this case is the same thing, but without the stigma of globals, and >> people don't argue back when you bring up the havey artillery of >> design patterns), or it has to be connected to a global or singleton >> which is your "application" object or whaterver. It's nothing that >> can't be solved, but it's either inconvenient or not very maintainable. >> >> One other drawback with the event-handler-as-procedure approach is >> that there can only be one instance of the window, because if you >> create a new window with the exact same names the event handler sub >> has no way to determine which window fired the event. This can be >> coded around at great inconvenience (with Perl, few things are >> impossible). >> >> My point is: If only the Window object (or the window object of the >> control) firing off the event was passed as the first parameter to the >> event handler everything would be so much easier to live with. Finding >> the event handler sub in the correct package (OO style) would be a boon. >> >> >> Actually, the result of my holiday hacking today is a module that >> pretty much does this. Win32::GUI::Window::Object >> http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/ >> >> The synopsis script (below) creates three distinct windows of the same >> class DemoWindow. The event handlers are methods on a subclass of >> Win32::GUI::Window, so the context ($self) for all events is the >> current Window::GUI::Window object. >> >> Consider this a proof-of-concept. A test of whether it could be done >> or not. I've had the idea for a long time, but never had the free time >> and motivation to actually do it. I have obviously not done anything >> real with this yet :) >> >> >> - Is this something that seems useful to proceed with? At least the >> concepts, if not the code? >> >> - Is this something that can easily be solved from within Win32::GUI >> XS code, passing the window object as the first variable ot the event >> handlers? Perhaps using Perl's OO mechanism so that the correct >> package is used? Doing it the real way is definitely more stable than >> my hack. >> >> - The subclassing isn't necessary, but could be useful. At the moment, >> with the objects as hash keys in the object, there is a high risk of >> clobbering them unintentionally, should people start subclassing >> Win32::GUI::Window en masse. Perhaps they could be moved to a >> "_controls" hash ref property of the window or something? Would that >> be difficult to use from XS code? >> >> >> >> So finally, an example program using Yet Another Event Model: >> http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/synopsis.pl.txt >> >> #!/usr/local/bin/perl -w >> >> use strict; >> use Data::Dumper; >> use Win32::GUI; >> use lib ("../lib"); >> use Win32::GUI::Window::Object; >> >> >> >> for (1..3) { >> my $id = int(rand(100)); >> my $win = DemoWindow->winCreate($id); >> $win->Show(); >> } >> >> Win32::GUI::Dialog(); >> >> >> >> >> >> package DemoWindow; >> >> #Inherit from the new Window-as-object class >> use base qw(Win32::GUI::Window::Object); >> >> >> >> #A demo property to give it some identity >> use Class::MethodMaker get_set => [ "no" ]; >> >> >> >> #Class method to create/build a window of this class. It >> #could eventually be a window built by TGL. >> # >> #This could be in the new() method as well, calling the >> #SUPER::new() to create the object, then setting the no() >> #property. >> # >> sub winCreate { my $pkg = shift; >> my ($no) = @_; >> >> my $self = $pkg->new( >> -left => 100 + int(rand(400)), >> -top => 50 + int(rand(200)), >> -width => 300, >> -height => 100, >> -name => "winMain", >> -text => "Window $no", >> ); >> >> $self->no($no); #Set the demo property >> >> my $btnHelloWorld = $self->AddButton( >> -name => "btnHelloWorld", >> -text => "Hello world!", >> -left => 10, >> -top => 10, >> -height => 20, >> -width => 100, >> ); >> >> return($self); >> } >> >> >> >> #Event handlers are ordinary methods, with $self as >> #the first parameter as usual. This gives context to the >> #event, making it possible to have many instances of the >> #same window class. >> >> sub winMain_Terminate { my $self = shift; >> print "winMain_Terminate from DemoWindow with no (" . $self->no . >> ")\n"; >> return(-1); >> } >> >> >> >> sub btnHelloWorld_Click { my $self = shift; >> my $no = $self->no(); >> print "btnHelloWorld_Click in DemoWindow no == $no\n"; >> $self->Text("Window $no - " . int(rand(100)) ); >> >> return(1); >> } >> >> >> >> __END__ >> >> >> /J >> -------- ------ ---- --- -- -- -- - - - - - >> Johan Lindström Sourcerer @ Boss Casinos jo...@ba... >> >> Latest bookmark: "ACM Queue - Code Spelunking Exploring Cavernous..." >> <http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=67&page=7> >> >> dmoz (1 of 4): /Arts/Music/Bands_and_Artists/T/ 20 >> >> >> >> ------------------------------------------------------- >> 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 >> Per...@li... >> 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. |
From: Jez W. <je...@je...> - 2004-01-05 14:34:57
|
Johan, I would find this functionality extremely useful. In the next couple of weeks I'll be attempting to implment multiple instances of the same windo= w. I was thinking of using the NEM and closures to implement an OO like approach - although I've yet to get past the thinking stage:) In my case, the application is likely to be long running and the user is likely to open and close multiple windows many times, which means I will have to "reuse" old windows, or I'll have a memory leak or worse on my hands. If this kind of functionality is included in the core, then the resources a window uses should be returned to the OS when it is closed/terminated. It may be worth talking to Aldo - I remember reading some comments from h= im suggesting that he was working on an improved model - which may (or may n= ot) achieve what you are suggesting. Cheers, jez. ----- Original Message -----=20 From: "Johan Lindstrom" <jo...@ba...> To: "Win32-GUI" <per...@li...> Sent: Monday, January 05, 2004 2:07 AM Subject: [perl-win32-gui-users] RFC: Yet another event model, anyone? When I first looked at Win32::GUI for the first time many many years ago (4? ok, not so many) I found it kind of confusing how the objects and events worked. Coming from an OO background and with experience from a few other window toolkits (VB and Borland TurboVision among others) I would have expected = to subclass the Window class, create an object, add controls to the object, and then I would defined methods in my subclass to be called when events fired. Kind of like this: package DemoWindow; #My DemoWindow is-a Window... use base qw(Win32::GUI::Window); #...but with event handlers for events that may fire sub btnOk_Click { my $self =3D shift; #the Window object #Change text of the clicked button $self->btnOk->Text( "Ok - " . int(rand(100)) ); return(1); } But that's not how it works. Instead, event handlers based on the -name o= f the windows and controls created. They are sub routines called in a procedural fashion which requires me as an application programmer to keep track of which window the event belongs to. This is not very convenient. I have not yet seen any "best practice" emerge for dealing with this. Either the window variable needs to be a global or a singleton (which in this case is the same thing, but without the stigma of globals, and peopl= e don't argue back when you bring up the havey artillery of design patterns= ), or it has to be connected to a global or singleton which is your "application" object or whaterver. It's nothing that can't be solved, but it's either inconvenient or not very maintainable. One other drawback with the event-handler-as-procedure approach is that there can only be one instance of the window, because if you create a new window with the exact same names the event handler sub has no way to determine which window fired the event. This can be coded around at great inconvenience (with Perl, few things are impossible). My point is: If only the Window object (or the window object of the control) firing off the event was passed as the first parameter to the event handler everything would be so much easier to live with. Finding th= e event handler sub in the correct package (OO style) would be a boon. Actually, the result of my holiday hacking today is a module that pretty much does this. Win32::GUI::Window::Object http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/ The synopsis script (below) creates three distinct windows of the same class DemoWindow. The event handlers are methods on a subclass of Win32::GUI::Window, so the context ($self) for all events is the current Window::GUI::Window object. Consider this a proof-of-concept. A test of whether it could be done or not. I've had the idea for a long time, but never had the free time and motivation to actually do it. I have obviously not done anything real wit= h this yet :) - Is this something that seems useful to proceed with? At least the concepts, if not the code? - Is this something that can easily be solved from within Win32::GUI XS code, passing the window object as the first variable ot the event handlers? Perhaps using Perl's OO mechanism so that the correct package i= s used? Doing it the real way is definitely more stable than my hack. - The subclassing isn't necessary, but could be useful. At the moment, wi= th the objects as hash keys in the object, there is a high risk of clobberin= g them unintentionally, should people start subclassing Win32::GUI::Window = en masse. Perhaps they could be moved to a "_controls" hash ref property of the window or something? Would that be difficult to use from XS code? So finally, an example program using Yet Another Event Model: http://www.bahnhof.se/~johanl/perl/Win32GUI/Window/synopsis.pl.txt #!/usr/local/bin/perl -w use strict; use Data::Dumper; use Win32::GUI; use lib ("../lib"); use Win32::GUI::Window::Object; for (1..3) { my $id =3D int(rand(100)); my $win =3D DemoWindow->winCreate($id); $win->Show(); } Win32::GUI::Dialog(); package DemoWindow; #Inherit from the new Window-as-object class use base qw(Win32::GUI::Window::Object); #A demo property to give it some identity use Class::MethodMaker get_set =3D> [ "no" ]; #Class method to create/build a window of this class. It #could eventually be a window built by TGL. # #This could be in the new() method as well, calling the #SUPER::new() to create the object, then setting the no() #property. # sub winCreate { my $pkg =3D shift; my ($no) =3D @_; my $self =3D $pkg->new( -left =3D> 100 + int(rand(400)), -top =3D> 50 + int(rand(200)), -width =3D> 300, -height =3D> 100, -name =3D> "winMain", -text =3D> "Window $no", ); $self->no($no); #Set the demo property my $btnHelloWorld =3D $self->AddButton( -name =3D> "btnHelloWorld", -text =3D> "Hello world!", -left =3D> 10, -top =3D> 10, -height =3D> 20, -width =3D> 100, ); return($self); } #Event handlers are ordinary methods, with $self as #the first parameter as usual. This gives context to the #event, making it possible to have many instances of the #same window class. sub winMain_Terminate { my $self =3D shift; print "winMain_Terminate from DemoWindow with no (" . $self->no . ")\n"; return(-1); } sub btnHelloWorld_Click { my $self =3D shift; my $no =3D $self->no(); print "btnHelloWorld_Click in DemoWindow no =3D=3D $no\n"; $self->Text("Window $no - " . int(rand(100)) ); return(1); } __END__ /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindstr=F6m Sourcerer @ Boss Casinos jo...@ba... Latest bookmark: "ACM Queue - Code Spelunking Exploring Cavernous..." <http://www.acmqueue.com/modules.php?name=3DContent&pa=3Dshowpage&pid=3D6= 7&page=3D7> dmoz (1 of 4): /Arts/Music/Bands_and_Artists/T/ 20 ------------------------------------------------------- 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_id=1278&alloc_id371&op=3Dick _______________________________________________ Perl-Win32-GUI-Users mailing list Per...@li... https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users |