Hi, Glad you think it's a good idea, because it's implemented now. I THINK i've stopped it crashing as well :) This is my first REAL bash at some new XS code instead of just fixing C bugs. So the fact that it works is pretty impressive. Anyway, it'll hit the CVS soon so keep your eyes peeled.
Steve ----- Original Message ----- From: "Glenn Linderman" <[EMAIL PROTECTED]> To: "Steve Pick" <[EMAIL PROTECTED]> Cc: "Win32 GUI Hackers" <perl-win32-gui-hackers@lists.sourceforge.net> Sent: Friday, December 05, 2003 2:26 AM Subject: Re: [perl-win32-gui-hackers] Proposition for NEM > Well, well, well. Should I use the "great minds think alike" line? > > Or is this just so obviously a good idea that we both have thought of it? > > Clearly there are some well-defined events that need to have particular > handling applied, and Win32::GUI needs to default to doing that handling. > > Clearly any event for which a handler exists, it would be nice to be > able to override or supplement the default handling. I suppose for full > generality, the hooks should define whether they are "pre-default > handling" hooks, or "post-default handling" hooks, but it seems that > most things in Windows are set up so that only "pre-default handling > hooks" are needed. But I'm no Windows expert, so correct me here if I'm > wrong. > > One of my most desired features for the NEM, other than getting the bugs > and incompletenesses out of it, is the ability to obtain a reference to > the "current handler", so that a new handler could be written to wrap > the "current handler", or to substitute for it for a while, and then put > it back. Without that, NEM is not very extensible. > > And the idea of defining the events for which the user can define hooks, > which is the gist of your message, is clearly the way to go for full > capability. It is not clear to me if such a handler should be placed in > Win32::GUI::Dialog/DoEvents/etc., or in the MessageLoops code, probably > the latter, but there are so many of them, and I don't even understand > fully why there are so many of them. So the former seems like a more > central location! > > When I was contemplating finishing or replacing Win32::GUI since Aldo > was "incognito" for an extended period, I considered discarding the > MessageLoops stuff entirely, putting the hooks you suggest into Dialog, > and discovering what else I didn't know, and how disastrous it would > have been to do so... but I decided the shortest path to a working > project would be to fix a few bugs in the old event model, and use it, > so that is what I am doing. > > BTW, I have seen/have a program that use PeekMessage extensively, as the > primary GUI interface. It does function, if properly manipulated. Said > program was not authored by me, however, so I don't feel I can > distribute it... but I could give you a pointer to the author if you > wish to ask him about it. > > > On approximately 12/4/2003 4:25 PM, came the following characters from > the keyboard of Steve Pick: > > Hello, > > > > Here's a nice idea: > > > > use Win32::GUI; > > my $win = new Win32::GUI::Window( > > -name => "Test", > > -left => 100, > > -top => 100, > > -width => 100, > > -height => 100, > > -onResize => \&Test_resize > > ); > > > > # Whenever we get WM_SETCURSOR, call perl sub setcursor with message > > parameters. > > $win->Hook(WM_SETCURSOR, \&setcursor); > > > > # ... some code ... > > > > # Reassign WM_SETCURSOR to go elsewhere > > > > $win->Hook(WM_SETCURSOR, \&changecursorback); > > > > # ... some more code ... > > > > # Now reset WM_SETCURSOR to trigger DefWndProc(). > > $win->UnHook(WM_SETCURSOR); > > > > Since we can never implement all the events the user might wish to catch in > > the NEM, this method lets the user define when they want to catch a specific > > event and handle it in Perl, and when they want to finish their capture. > > This beats the hell out of using GetMessage (non-blocking, faster, simpler) > > and PeekMessage (peekmessage always seems to return nothing anyway). > > > > What do you think? Should I implement this? > > > > Steve. > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us help > > YOU! Click Here: http://sourceforge.net/donate/ > > _______________________________________________ > > Perl-Win32-GUI-Hackers mailing list > > Perl-Win32-GUI-Hackers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers > > > > > > -- > Glenn -- http://nevcal.com/ > =========================== > Like almost everyone, I receive a lot of spam every day, much of it > offering to help me get out of debt or get rich quick. It's ridiculous. > -- Bill Gates > > And here is why it is ridiculous: > The division that includes Windows posted an operating profit of $2.26 > billion on revenue of $2.81 billion. > --from Reuters via > http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html > > So that's profit of over 400% of investment... with a bit more > investment in Windows technology, particularly in the area of > reliability, the profit percentage might go down, but so might the bugs > and security problems? Seems like it would be a reasonable tradeoff. > WalMart earnings are 3.4% of investment. > >
