From: Dave M. <qw...@ma...> - 2001-03-01 21:50:53
|
hey. do event handler routines (ie. sub Button1_Click) have to be in the main namespace or in the namespace in which they were created? can objects be assigned and event handler? (ie. $myButton->Event(Click => \&coderef);). if not, twould be nice. id be willing to do the work if it didnt involve too much serious XS stuff. it seems to me that this module wasnt really meant to be used in an OO application? can anyone out there tell me otherwise? dave |
From: Aldo C. <da...@pe...> - 2001-03-02 10:47:10
|
Dave Moore wrote: > hey. > > do event handler routines (ie. sub Button1_Click) have to be in > the main namespace or in the namespace in which they were created? no, they can be anywhere: just add the namespace to your control's name and the event will be searched in that namespace. example: $Window->AddButton( -name => "Buttons::Button1", # etc. ); package Buttons; sub Button1_Click { # etc. } > can objects be assigned and event handler? (ie. > $myButton->Event(Click => \&coderef);). if not, twould be nice. > id be willing to do the work if it didnt involve too much serious > XS stuff. I'm working on it, it's basically done (the version is on CVS) but there are still some issues to solve. and yes, it involves serious XS stuff ;-) > it seems to me that this module wasnt really meant to be used in > an OO application? can anyone out there tell me otherwise? I maybe be ignorant, but what the heck do you mean by 'an OO application'? :-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; |
From: Eric B. <er...@eb...> - 2001-03-02 16:16:07
|
On Fri, 2 Mar 2001, Aldo Calpini wrote: > > it seems to me that this module wasnt really meant to be used in > > an OO application? can anyone out there tell me otherwise? > > I maybe be ignorant, but what the heck do you mean by 'an OO > application'? :-) He probably means being able to open multiple instances of a window or being able to subclass window or control behavior. Right now the only connection a control has to the rest of the program is through the control name. This means that to open two identical windows where the controls on each window refer to the right window's values you have to use app-unique names for controls and then dynamically define subs with lexical references to those values. I was considering doing this with package names (one package per window, consistant control names, package is destroyed after window closes) but havn't actually coded it yet. I hope I am missing the simple, good way to do this. Example below. - Eric B. -- "Pasteurized From Concentrate" ============================================================== use Win32::GUI; # # An example of window instances in practice. # # Note that if we needed to catch Change events on the text boxes # those would need coded names too. # # Some of this could be cleaned by having small lexical subs which # forward to normal methods but you still need the closures # somewhere to hold a reference to disambiguate the window. # # In a real MVC app I would usually refer directly to controls very # little; instead the lexical ref would be to a model object doing # the work. I left that out for clarity. # my $prior_unique_window_code = 0; my $open_window_count = 0; sub build_add_window { my $code = ++$prior_unique_window_code; my $Window = new Win32::GUI::Window( -title => "Add Numbers ($code)", -left => 100, -top => 100, -width => 220, -height => 200, -name => "Window$code", -style => WS_MINIMIZEBOX | WS_CAPTION | WS_SYSMENU, ); $Window->AddTextfield( -name => "InputA", -left => 10, -top => 10, -text => "5", -width => 180, -height => 22, ); $Window->AddTextfield( -name => "InputB", -left => 10, -top => 38, -text => "8", -width => 180, -height => 22, ); $Window->AddButton( -name => "Add$code", -text => "Add", -left => 80, -top => 66, ); $Window->AddTextfield( -name => "Output", -left => 10, -top => 94, -text => "?", -width => 180, -height => 22, ); $Window->AddButton( -name => "CloneWindow$code", -text => "Clone Window", -left => 55, -top => 122, ); $open_window_count++; $Window->Show(); *{"Window$code\_Terminate"} = sub { # Free refs hidden in the subs undef *{"Window$code\_Terminate"}; undef *{"Add$code\_Click"}; undef *{"CloneWindow$code\_Click"}; $open_window_count--; return $open_window_count > 0 ? 1 : -1; }; *{"Add$code\_Click"} = sub { $Window->Output->Text( $Window->InputA->Text + $Window->InputB->Text ); }; *{"CloneWindow$code\_Click"} = sub { my $NewWindow = build_add_window(); $NewWindow->InputA->Text( $Window->InputA->Text ); $NewWindow->InputB->Text( $Window->InputB->Text ); $NewWindow->Output->Text( $Window->Output->Text ); }; return $Window; } build_add_window(); Win32::GUI::Dialog(); |
From: Aldo C. <da...@pe...> - 2001-03-02 16:58:06
|
Eric Bennett wrote: > He probably means being able to open multiple instances of a > window or being able to subclass window or control behavior. I'm afraid I still don't get the exact point (I'm tired, sorry :-). > Right now the only connection a control has to the rest of the > program is through the control name. This means that to open two > identical windows where the controls on each window refer to the > right window's values you have to use app-unique names for controls > and then dynamically define subs with lexical references to those > values. this is more clear. the New Event Model I'm trying to build will pass a reference to the object that fired the event as its first parameter, so this issue will be solved. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; |
From: Eric B. <er...@eb...> - 2001-03-02 19:35:59
|
On Fri, 2 Mar 2001, Aldo Calpini wrote: > this is more clear. the New Event Model I'm trying to build will > pass a reference to the object that fired the event as its first > parameter, so this issue will be solved. This would be very helpful. The feature which would make this complete for me is if each control had a tag value which could hold a scalar reference. Then it would be simple to segue into an OO approach: sub CommonButtonName_Clicked { my ( $source_button ) = @_; $source_button->Tag->execute_command_and_log_undo(); } Tags would also be handy for things like radiobutton data values. I know very little about Win32::GUI internals so I have no idea how feasable this would be to implement. - Eric B. -- "Pasteurized From Concentrate" |
From: Aldo C. <da...@pe...> - 2001-03-05 14:45:55
|
Eric Bennett wrote: > This would be very helpful. The feature which would make this > complete for me is if each control had a tag value which could > hold a scalar reference. a scalar reference to what? > Then it would be simple to segue into an OO approach: > > sub CommonButtonName_Clicked { > my ( $source_button ) = @_; > > $source_button->Tag->execute_command_and_log_undo(); > } this is completely unclear to me. what is 'execute_command_and_log_undo'? a method in some package? what is supposed $source_button->Tag to report? maybe you mean it to act like: execute_command_and_log_undo( $source_button ); but, if this is what you mean, I don't see why you should want it (it's just that you like the '->'? :-) and I don't see any precedent in a Perl module for such things. I don't think you want to patch *any* Perl module to be able to write: my $OBJECT = Something->new; $OBJECT->execute_command_and_log_undo(); when 'execute_command_and_log_undo' is a sub in your script. > Tags would also be handy for things like radiobutton data > values. please elaborate something more on your example, there may be something I'm missing. > I know very little about Win32::GUI internals so I have no > idea how feasable this would be to implement. I need to understand first *what* to implement and *why* implement it. then it should be a breeze ;-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; |
From: Eric B. <er...@eb...> - 2001-03-05 16:06:30
|
On Mon, 5 Mar 2001, Aldo Calpini wrote: > this is completely unclear to me. Sorry, I was unclear. A tag is a scalar value associated with the control which is for application use. It can be fetched and set but has no effect on control behavior. Why is this useful? Say you have radio buttons for day of the week. The datum you need is 0-6 for Sunday-Saturday. Right now you need seven _Click subs which each set a different value or which call on a sub that does the checking. With tags you could put the correct data value in the tag when creating the buttons and give them all the same name. Then sub DayOfWeekRadioButton_Click { my ( $source_radiobutton ) = @_; our $day_of_week_value = $source_radiobutton->Tag; } would work for all of them. If I was doing Model/View/Controller with Win32-GUI then I would use the tag value to hold a reference to the model object for that control: sub SomeText_Change { my ( $control ) = @_; # Get the object representing what this textbox shows my $model_value_holder = $control->Tag; # Inform the abstract model that the value has changed $model_value_holder->set_value( $control->Text ); } The motive for doing this is to get as much code out of the GUI elements as possible. This helps testing the logic seperately from the GUI and helps to limit where errors can occur. So usually I would have all my text boxes, all my buttons, etc execute the same routines for dealing with their model object. Normally I would do this by subclassing the text control to do model-specific handling and then using instances of the subclassed control. Since the perl objects in Win32-GUI are just handles I don't know if that would make sense here. - Eric B. -- "Pasteurized From Concentrate" |
From: Dave M. <da...@no...> - 2001-03-07 11:53:24
|
> Eric Bennett wrote: > > He probably means being able to open multiple instances of a > > window or being able to subclass window or control behavior. > > I'm afraid I still don't get the exact point (I'm tired, sorry :-). > i dont know what i meant either (i was tired too). > > Right now the only connection a control has to the rest of the > > program is through the control name. This means that to open two > > identical windows where the controls on each window refer to the > > right window's values you have to use app-unique names for controls > > and then dynamically define subs with lexical references to those > > values. > > this is more clear. the New Event Model I'm trying to build will > pass a reference to the object that fired the event as its first > parameter, so this issue will be solved. > that will be nice, but there is still the issue of name space. having to name each control in some sort of global space...ie. $MW->Button(Name => 'MyButton1'); gets hard to keep track when you want to break your program into objects or even if it gets really big. i dont know how else you could do it though. and seeming as how the topic was event handlers, i think it would be cool if i could say: my $btn = $MainW->Button(); $btn->add_handler('Click', \&some_sub); sub some_sub { my ($object, $event) = @_; } instead of making a subroutine with Name_Click. it would clean up all my scripts alot. for eg cancel buttons all do the same thing. its easier to register a routine for your events than to declare a subroutine that calls a subroutine. just my humble opinion dave |
From: Aldo C. <da...@pe...> - 2001-03-07 13:05:15
|
Dave Moore wrote: >> this is more clear. the New Event Model I'm trying to build will >> pass a reference to the object that fired the event as its first >> parameter, so this issue will be solved. > > that will be nice, but there is still the issue of name space. > having to name each control in some sort of global space...ie. > > $MW->Button(Name => 'MyButton1'); > > gets hard to keep track when you want to break your program into > objects or even if it gets really big. i dont know how else you > could do it though. but with the New Event Model (codename 'NEM') you don't need a name at all. > and seeming as how the topic was event handlers, i think it would > be cool if i could say: > > my $btn = $MainW->Button(); > $btn->add_handler('Click', \&some_sub); > > sub some_sub { > my ($object, $event) = @_; > } > > instead of making a subroutine with Name_Click. it would clean up > all my scripts alot. for eg cancel buttons all do the same thing. > its easier to register a routine for your events than to declare a > subroutine that calls a subroutine. > > just my humble opinion that's exactly what the NEM stands for. right now, the synopsis is: $MainW->AddButton( -text => "Click Me", -pos => [ 50, 50 ], -events => { -Click => \&some_sub, # or # -Click => "some_sub", # or # -Click => sub { print 'I got a click!'; } }, ); there will be, of course, a method to add, change and remove events after the object creation. the latest version on CVS does already support the synopsis above; I'm having serious problems supporting a NEM for menus :-( if someone wants to help me with this just ring the bell... cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; |