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
