From: Marcus <li...@wo...> - 2001-09-25 17:13:12
|
Has anybody created a remote FTP directory browser (for file selction)? I have written one for Perl/Tk, but if there's already one for Win32::GUI, then I won't need to rewrite it. Thanks, Marcus |
From: Mark W. <ma...@il...> - 2001-11-04 00:29:07
|
Someone please... save me before I choke! Please say it isn't so!! Tonight I really started to build a serious heavy-duty Win32::GUI application, and I immediately hit a wall: Is it really not possible to (usefully) program in Win32::GUI while under "use strict"?!? I say this because there appears to be **nothing** passed to the event-handling subroutines - not even a reference to the widget itself! This, IMHO, is absolutely insane! That means that all of my widget refs, and every variable that is required in the event-handling subroutines, have to be global variables... which would make comp-sci professors roll over in their future graves... a "good" program should never need to have a *single* global variable, let alone *every* variable being global. If even the widget ref was sent to the event-handler I could attach the subroutine's required variables to its hash, but as things are it seems to break every rule I know about "good" programming style. I must be missing something... Please, someone, tell me that it doesn't really work this way... Mark |
From: Morbus I. <mo...@di...> - 2001-11-04 01:43:01
|
>Is it really not possible to (usefully) program in Win32::GUI while under >"use strict"?!? I say this because there appears to be **nothing** passed >to the event-handling subroutines - not even a reference to the widget It's certainly possible - but your complaint seems to be more about global variables as opposed to 'use strict'. As a rough example, AmphetaDesk uses Win32::GUI, under 'use strict' and -w. And yes, within the Windows routines (/lib/Windows.pl), I use global variables. Que sera. http://www.disobey.com/amphetadesk/ -- Morbus Iff ( i am your scary godmother ) http://www.disobey.com/ && http://www.gamegrene.com/ please me: http://www.amazon.com/exec/obidos/wishlist/25USVJDH68554 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
From: <pko...@me...> - 2001-11-04 09:10:07
|
> Tonight I really started to build a serious heavy-duty Win32::GUI > application, and I immediately hit a wall: I had no problems with "use strict" (you can have a look at my source code http://sourceforge.net/projects/auctioneer/) But I hit a wall with Win32::GUI in connection with Win32::OLE! When using Win32::OLE and a Win32::GUI, you will get an "Can't locate auto/....al" error. Peter > -----Original Message----- > From: per...@li... > [mailto:per...@li...]On Behalf Of > Mark Wilkinson > Sent: Sunday, November 04, 2001 1:31 AM > Cc: per...@li... > Subject: [perl-win32-gui-users] ACK!! Sputter Cough... say it isn't so! > > > Someone please... save me before I choke! Please say it isn't so!! > Tonight I really started to build a serious heavy-duty Win32::GUI > application, and I immediately hit a wall: > > Is it really not possible to (usefully) program in Win32::GUI while under > "use strict"?!? I say this because there appears to be **nothing** passed > to the event-handling subroutines - not even a reference to the widget > itself! This, IMHO, is absolutely insane! That means that all of my > widget refs, and every variable that is required in the event-handling > subroutines, have to be global variables... which would make comp-sci > professors roll over in their future graves... a "good" program should > never need to have a *single* global variable, let alone *every* variable > being global. If even the widget ref was sent to the > event-handler I could > attach the subroutine's required variables to its hash, but as things are > it seems to break every rule I know about "good" programming style. > > I must be missing something... Please, someone, tell me that it doesn't > really work this way... > > Mark > > > > _______________________________________________ > Perl-Win32-GUI-Users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > |
From: Mark W. <ma...@il...> - 2001-11-04 12:26:44
|
Hey Peter! Wie geht's? :-) Hey Morbus! > I had no problems with "use strict" (you can have a look at my source code > http://sourceforge.net/projects/auctioneer/) The real question is this: how do you get your variables into your widget event control subroutines? e.g. the code below: use strict; my $x = 1; sub Button_Click { ++$x } this will fail because there is no way (AFAIK) to pass $x into the subroutine as the result of a click... I had a look at the AmphetaDesk code that Morbus suggested (I haven't looked at auctioneer yet...), but that doesn't seem to use strict in all of its modules, so that doesn't count. I'm still not convinced that it is possible... M |
From: Mark W. <ma...@il...> - 2001-11-04 12:43:33
|
> I had a look at the AmphetaDesk code that Morbus > suggested but that doesn't seem to use > strict in all of its modules, so that doesn't count. in fact, it explicitly declares them as globals in the use vars statement... I am trying to *avoid* declaring all of my variables as globals... M |
From: Morbus I. <mo...@di...> - 2001-11-04 16:51:55
|
>in fact, it explicitly declares them as globals in the use vars statement... >I am trying to *avoid* declaring all of my variables as globals... Ah. Ok. I was showing AmphetaDesk as "yes, it can be done with strict", and also gave the warning you just re-stated: At 8:39 PM -0500 11/3/01, Morbus Iff wrote: >And yes, within the Windows routines (/lib/Windows.pl), >I use global variables. Que sera. -- Morbus Iff ( i am your scary godmother ) http://www.disobey.com/ && http://www.gamegrene.com/ please me: http://www.amazon.com/exec/obidos/wishlist/25USVJDH68554 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
From: Marcus <li...@wo...> - 2001-11-04 13:53:00
|
On 04.11.01 at 06:28 Mark Wilkinson wrote: >The real question is this: how do you get your variables into your widget >event >control subroutines? e.g. the code below: > >use strict; >my $x = 1; > >sub Button_Click { > ++$x >} Well, I think you need to declare subs as: sub main::Button_Click { or at the latest when you have an external widget, your events won't be processed. I just figured that one out again, or should I say I remembered what I'd read in the manual :-) and for your $x, call it $main::x. I've been wrestling with this stuff too. I just wrote a remote FTP directory selector which sits in a separate module and in order to set the Textfield I have to say $main::win->RemoteDirectoryTextField->Text("..."); You can't use a return value because that gets sent back to Win32::GUI's main loop and that wants to receive 0,1, or -1 only. I think that's correct isn't it? Marcus |
From: Johannes G. <in...@de...> - 2001-11-05 09:39:10
|
Guten Tag Marcus, Am Sonntag, 4. November 2001 um 14:52 schrieben Sie: M> On 04.11.01 at 06:28 Mark Wilkinson wrote: >>The real question is this: how do you get your variables into your M> widget >>event >>control subroutines? e.g. the code below: >> >>use strict; >>my $x = 1; >> >>sub Button_Click { >> ++$x >>} M> Well, I think you need to declare subs as: M> sub main::Button_Click { M> or at the latest when you have an external widget, your events won't be M> processed. I just figured that one out again, or should I say I M> remembered what I'd read in the manual :-) M> and for your $x, call it $main::x. Hello, i'm new to Win32::GUI .. so i've a question about the options of the widgets. Is ther a list of all available options to the relevant widgets ...? thx a lot for your help ;-) Hannes -- Mit freundlichen Grüssen Johannes Gamperl mailto:in...@de... |
From: Johannes G. <in...@de...> - 2001-11-05 09:47:01
|
ups .. sorry i've forgott to delete the replay information on my message before :-)) sorry Marcus :-) Hannes -- Mit freundlichen Grüssen Johannes Gamperl mailto:in...@de... |
From: Johan L. <jo...@ba...> - 2001-11-04 16:30:57
|
At 18:31 2001-11-03 -0600, Mark Wilkinson wrote: >Someone please... save me before I choke! Please say it isn't so!! >Tonight I really started to build a serious heavy-duty Win32::GUI >application, and I immediately hit a wall: > >Is it really not possible to (usefully) program in Win32::GUI while under >"use strict"?!? I say this because there appears to be **nothing** passed This isn't so. But it's unfortunate that none of the provided sample scripts use strict and warnings. >to the event-handling subroutines - not even a reference to the widget >itself! This, IMHO, is absolutely insane! No, but it's very impractical. I felt the same thing when I started using Win32::GUI. >That means that all of my widget refs, and every variable that is required >in the event-handling subroutines, have to be global variables... Obviously you haven't reached the "Singleton" chapter in your patterns book :) >which would make comp-sci professors roll over in their future graves... a >"good" program should never need to have a *single* global variable, let >alone *every* variable being global. If even the widget ref was sent to >the event-handler I could attach the subroutine's required variables to >its hash, but as things are it seems to break every rule I know about >"good" programming style. What you need is an entry point to your window variables. From there you can access all the contained controls. 1. You can do this with e.g. a singleton class for each of your windows. In each event handler you instansiate a new (i.e. the same) object of your class wich contains a property with your window object. Examples: The GUI Loft and Perl Oasis: http://www.bahnhof.se/~johanl/perl/ 2. You can also do this with globals. Yes, it's poor form. In general it's a bad idea. But you should understand _why_ it's bad before you shun them. Globals are bad because (among other things) they introduce side effects at the largest possible scope. They increase what you need to know about a piece of code in order to understand it. Bad, bad, bad. The way Win32::GUI works, they're very useful. After all, the nice, cool, com-sci approved singleton is really just an entry point to a single object -- a global object (with a twist, admittedly). And the way the globals are used makes it possible to think about this like we were back in Object Oriented Land again * relief * But polluting the global name space with loads of vars is not necessary if you use a single list or hash for storing the window objects. That way you only have one global variable to keep track of. Example: This is how you manage your windows built with The GUI Loft. An event handler might look like this: sub ::btnFetch_Click { defined(my $win = $Win32::GUI::Loft::window{winFetch}) or return(1); my $url = $win->tfURL->Text(); #Do something with the $url return(1); } I'm not saying that it wouln't be _better_ having the window object passed to the event handler (it would), I'm saying it doesn't have to be all that bad using a single global to accomplish almost the same thing. /J ------ ---- --- -- -- -- - - - - - Johan Lindström Boss Casinos Sourcerer jo...@ba... http://www.bahnhof.se/~johanl/ If the only tool you have is a hammer, everything tends to look like a nail |
From: Mark W. <ma...@il...> - 2001-11-04 16:53:06
|
Johan Lindstrom wrote: > > I say this because there appears to be **nothing** passed > This isn't so. well... an examination of @_ at the beginning of the event handling subroutines says it is so... nothing is *passed* > No, but it's very impractical. I felt the same thing when I started using > Win32::GUI. Glad to have company :-) > Obviously you haven't reached the "Singleton" chapter in your patterns book :) not yet, no ;-) > What you need is an entry point to your window variables. From there you > can access all the contained controls. Window variables, yes, but other program variables (which may be required by that subroutine) no. > But polluting the global name space with loads of vars is not necessary if > you use a single list or hash for storing the window objects. That way you > only have one global variable to keep track of. agreed... in fact, Morbus does exactly this and I can see that this is how I will have to proceed. Still, this architecture really does prevent you from achieving a lot of OO functionality (eg. extension). This is one of the main reasons that I wanted to mix Win32GUI and Tk - in Tk the widget ref itself is the first thing passed into all event handlers, so I always know which widget I am dealing with. Granted, Win32GUI handles this in its own way, by requiring that each widget have a "name", and that name becomes part of the name of the event-handling subroutine... but... ugh! If I am dynamically generating multiple copies of the same widget (thus with the same name) how do I know which instance was clicked if the widget ref is not passed back to the event handler? > I'm not saying that it wouln't be _better_ having the window object passed > to the event handler (it would), I'm saying it doesn't have to be all that > bad using a single global to accomplish almost the same thing. Agreed... it isn't "all that bad", but it is limiting/frustrating nonetheless... especially given how simple it would be to add this functionality (i.e. the widget ref must be available inside of the widget code itself, deep in the guts of Win32GUI, and thus be available to the code making the callback... so there is no obvious reason why it couldn't be passed...) It would be nice to at least be able to define a hash or a list of variables during widget construction that would be passed to any event handler. ... na ja... just me being grumpy again :-) Thanks (everyone!) for all of your tips! Cheers, M |
From: Johan L. <jo...@ba...> - 2001-11-04 17:15:14
|
At 10:55 2001-11-04 -0600, Mark Wilkinson wrote: > > > I say this because there appears to be **nothing** passed > > This isn't so. > >well... an examination of @_ at the beginning of the event handling >subroutines >says it is so... nothing is *passed* Ah. I was referring to your comment about using strict. Some things are passed to some types of event handlers, but never the window or control itself. > > What you need is an entry point to your window variables. From there you > > can access all the contained controls. > >Window variables, yes, but other program variables (which may be required >by that >subroutine) no. Ok, then take a look at the Singleton approach in TGL and Perl Oasis. They use one singleton for each window, but you can have one "application" singleton which contains the window objects and the rest of your application logic. >Granted, Win32GUI handles this in its own way, by requiring that each >widget have >a "name", and that name becomes part of the name of the event-handling >subroutine... but... ugh! If I am dynamically generating multiple copies >of the >same widget (thus with the same name) how do I know which instance was >clicked if >the widget ref is not passed back to the event handler? You don't do that. Empty your glass before you fill it. If you create controls dynamically, you don't give them the same name. If you create controls dynamically, you also create the event handlers dynamically (probably they just call some other sub to do the actual processing). Example of creating a Click event handler that passes a certain object ($objControl) for each control to a single sub: #Create the event handler my $perlEvent = qq{ { my \$obj = \$objControl; #Nice little closure sub ::${name}_Click { #Adding new subs _will_ leak memory... ::mnuPopupSelect(\$obj); } } }; eval $perlEvent; #...not to mention string eval print "Error: $@" if($@); (I have since learned that there are better ways than "eval STRING" to add subs.) >Agreed... it isn't "all that bad", but it is limiting/frustrating >nonetheless... >especially given how simple it would be to add this functionality (i.e. >the widget >ref must be available inside of the widget code itself, deep in the guts of >Win32GUI, and thus be available to the code making the callback... so >there is no >obvious reason why it couldn't be passed...) I thought so too but then I looked in the XS code. While it's obviously doable (most things are), I'm not convinced it's a walk in the park. /J ------ ---- --- -- -- -- - - - - - Johan Lindström Boss Casinos Sourcerer jo...@ba... http://www.bahnhof.se/~johanl/ If the only tool you have is a hammer, everything tends to look like a nail |
From: Mark W. <ma...@il...> - 2001-11-04 20:36:41
|
> Example of creating a Click event handler that passes a certain object > ($objControl) for each control to a single sub: > #Create the event handler > my $perlEvent = qq{ > { > my \$obj = \$objControl; #Nice little closure > sub ::${name}_Click { #Adding new subs _will_ leak memory... > ::mnuPopupSelect(\$obj); > } > } > }; > eval $perlEvent; #...not to mention string eval > print "Error: $@" if($@); this is very pretty (esp. the sneaky closure at the beginning!! trez cool!) I'll give that a try when I go back to my other machine later today... I still can't help but say "it shouldn't take cool and sneaky tricks to accomplish this...". :-) > I thought so too but then I looked in the XS code. While it's obviously > doable (most things are), I'm not convinced it's a walk in the park. Hmmm... I was probably assuming too much. I haven't looked at that code, but I assumed that the widget that was being manipulated would 'intuitively' know about itself, and thus events involving that widget could easily send the widget-ref to the callback... unless the widget-event and the widget are somehow "separated" (e.g. if the event triggered is based on global mouse-coordinates, rather than being triggered from within the widget... ugh!) Anyway, your code example is really sweet! I think between your example, and Morbus' global hash-ref-trash-can idea I can work around the problems that I have had so far. Thanks guys! Mark |
From: Mark W. <ma...@il...> - 2001-12-21 13:01:06
|
Hi group! I'm stumped. I have a bit of code that I designed on my W2000 machine. Perfect. But when I moved it to my Win98 machine it didn't work. I have narrowed it down to the Win32GUI part, and attach the trimmed-down relevant (simple) sections of code to this message. The script and module I attach here have been tested on both machines and I see the same result: things work as expected on the W2000, but on W98 the menu is never drawn - it is just a transparent bar along the top of the window. AFAIK my two installations of Win32GUI are identical (they should be since I only downloaded it once, and then passed it between my machines over my LAN). I don't know if it is the underlying OS that is causing the problem, or if there is something else different between the two machines, but it is certainly the first time I have ever seen a Perl script work on one machine and not another! I was amazed!! Any advice is appreciated :-) Mark |
From: Mark W. <ma...@il...> - 2001-12-22 15:45:33
|
The solution, apparently, is that the reference to the Menu object must be passed back to the main script; apparently the menu-ref is NOT encapsulated inside of the Window object that contains it... which is counter-intuitive, and unlike any other perl module I have ever seen... ---------------------------------------- this pseudo-code does NOT work: my $window=Module->new; $window->Show(); Win32::GUI::Dialog(); package Module; $menu = Win32::GUI::MakeMenu (blah blah) $window=Win32::GUI::Window->new(-menu => $menu) return $window ----------------------------------------- this pseudo-code DOES work: my ($window, $menu)=Module->new; $window->Show(); Win32::GUI::Dialog(); package Module; $menu = Win32::GUI::MakeMenu (blah blah) $window=Win32::GUI::Window->new(-menu => $menu) return ($window, $menu) ------------------------------------------- I have no idea why it worked on one OS and not the other, but still... it is the most bizzarre thing I have ever come across while using Perl! It is such bizzarre behavior that I am tempted to call it a bug in Win32GUI, rather than just a quirk... Anyway, in case anyone else ever has this problem, that is the solution :-) Merry Christmas everyone! M |
From: Johan L. <jo...@ba...> - 2001-12-23 21:54:59
|
At 09:48 2001-12-22 -0600, Mark Wilkinson wrote: >The solution, apparently, is that the reference to the Menu object must be >passed back to the main script; apparently the menu-ref is NOT encapsulated >inside of the Window object that contains it... which is >counter-intuitive, and >unlike any other perl module I have ever seen... The same goes with Bitmap objects you create, they have to stay in scope while the bitmap is in use by e.g. a Label control. /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos jo...@ba... Latest bookmark: "Design Patterns in Dynamic Programming" http://www.norvig.com/design-patterns/ |
From: Mark W. <ma...@il...> - 2001-12-24 14:10:38
|
Is this considered...ummm... "normal" behavior?? What is it about the architecture of the Win32GUI modules that makes it work this way? It is really the most peculiar thing I have ever seen, and breaks every model for OO programming that I know of... (i.e. that the contents of an object must be maintained as references outside of the object for them to remain in scope) M Johan Lindstrom wrote: > At 09:48 2001-12-22 -0600, Mark Wilkinson wrote: > >The solution, apparently, is that the reference to the Menu object must be > >passed back to the main script; apparently the menu-ref is NOT encapsulated > >inside of the Window object that contains it... which is > >counter-intuitive, and > >unlike any other perl module I have ever seen... > > The same goes with Bitmap objects you create, they have to stay in scope > while the bitmap is in use by e.g. a Label control. > > /J > > -------- ------ ---- --- -- -- -- - - - - - > Johan Lindström Sourcerer @ Boss Casinos jo...@ba... > > Latest bookmark: "Design Patterns in Dynamic Programming" > http://www.norvig.com/design-patterns/ > > _______________________________________________ > Perl-Win32-GUI-Users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users |
From: Johan L. <jo...@ba...> - 2001-12-24 18:03:33
|
At 08:12 2001-12-24 -0600, Mark Wilkinson wrote: >Is this considered...ummm... "normal" behavior?? > >What is it about the architecture of the Win32GUI modules that makes it work >this way? It is really the most peculiar thing I have ever seen, and breaks >every model for OO programming that I know of... (i.e. that the contents of an >object must be maintained as references outside of the object for them to >remain >in scope) Some Win32::GUI Perl objects contain handles to Win32 (os level) structures, which are deallocated once the Perl object is destroyed. That might be considered a good thing. What might be considered a bad thing is that some Win32::GUI controls doesn't take the responsibility to keep the reference count for the object up so it doesn't get garbage collected and destroyed while in use (if you declared it as a lexical variable). So you'll have to do that explicitly by e.g. assigning it to the property of another, more persistent object, or to a package var that never goes out of scope. /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos jo...@ba... Latest bookmark: "Troubleshooting Guide" <http://manuals.sybase.com/onlinebooks/group-rs/rsg1100e/rs_tsg/@Generic__BookView/4140;cs=default;ts=default> |