From: Stephen P. <Ste...@uc...> - 2003-12-05 12:37:03
|
Hi Aldo, >1) you can't easily (I mean, without a lot of effort) intercept all > kind of messages. <snip> I'm aware of this. Currently this is not meant as a simplicity feature; the NEM does that already. It's meant as something for people who know what they're doing when the NEM won't do, so they can process events without recompiling the module. Hackers should be aware of where their message is going to be going. The NEM supports a simpler interface to windows messaging, this hooking event model offers a more complicated one which supports all the messages that the NEM does not. >2) getting out something useful from wParam and lParam may be really > hard sometimes, and you would need a lot of pack() and unpack() > and a deep knowledge of how C (and the Windows SDK) manages memory > or you risk to blow up things very easily. This is true. I really should have offered more than just the wParam and lParam, but since it's not meant for your "average" user right at the moment, it doesnt matter. Once you start catering for people not knowing stuff, you end up limiting capabilities in favor of simplicity. This IS simple for people who have the brains to read a few lines of MSDN, and they'd have to do that anyway to learn about the constants for messages. >3) this may clash with Win32::GUI's own message processing. what to > do when you hook something to WM_NOTIFY, for example? if this > comes before what Win32::GUI already does, you may break things > and your GUI will be completely disfunctional. It doesnt. All the processing on hooks is done AFTER AND IN ADDITION TO any other NEM message processing. >4) if not used properly, it could also slow things a lot. there > are some messages (like WM_SETCURSOR for example) that are > sent several times a second to a window. calling a Perl sub > each time such an event is seen will cause your program to be > as slow as a slug. True, but since the current Win32::GUI NEM calls my message handlers 40 or 50 times for a simple mousedown event for reasons I can NOT figure out (believe me, I've hunted and hunted for the cause), it isn't the biggest problem currently. If this methodology slows down your application, just don't use it. Find another way. I actually wrote this routine for capturing WM_SETCURSOR messages, which should only be sent when the OS has reset the cursor to the default class cursor, and that SHOULD usually only happen on mouse move. Since there are already NEM events that generate perl calls potentially hundreds of times per second (-onMouseMove, -onResize for example), I can't see much justification in this point. =20 >5) to summarize points 1-4, this is a nice feature when (and if) you > have the knowledge of the Windows GUI internals, but it has the > following drawbacks: > - is potentially dangerous and prone to be abused in all sorts > of nasty ways I've captured every kind of message that the NEM supports already with it and havent found a problem. The only potential problem is that you have to watch your return values in handlers. If you capture WM_PAINT and return 0, the window just won't be repainted. However this is exactly the behaviour I would expect and desire from such functionality. If I want to discard PAINT messages then I should be able to. The Hook and UnHook routines are meant for hacking more than anything, for doing things that the NEM cannot currently do. > - is absolutely impossible to document it properly, and this will > be an inevitable cause of frustration to the end user A lot of Win32::GUI needs documentation and I am planning on writing up and correcting a lot of issues with the current docs, and maybe PODifying it all over the weekend. Yes Hook and UnHook are not easy to document, but then neither is PeekMessage() or GetMessage(). It's difficult to document the pitfalls of capturing messages and returning the wrong values, but it's easy to say "Read the API documentation on message handling". - it may cause "cargo-cult" programming that in the long run will do more harm than good (see the experience with -style) People will always do things badly. Currently I can think of a few much nastier ways to do this, most of which involve splatting in a ton of new WM_XXX events in GUI_MessageLoops.cpp and recompiling. That is horrible, especially since they're now running an incompatible version of Win32::GUI if they do it, so none of their releases will work with other people's libs. I'm unsure of the cargo-cult thing, i think that people will tend to favour the NEM over this since the NEM is considerably easier to use and provides custom information on the event that occurred. I was doing the horrible method, and I'm thanking heaven that i dont have to do that anymore (I take my software home, it doesnt work! I left my fixed version of Win32::GUI at work! damn! etc.). > >all in all, I think this is a good idea (the very first version of >Win32::GUI used a message loop where all WM_* were sent directly to >a Perl subroutine, but soon I realized that this was not a Good >Thing at all). Yeah I thought of doing that but then immediately thought "aaargh kludge". > I don't think this should be categorized as NEM, but as >PUEM (Power User Event Model) instead, and this should be something >available only on *explicit* request by the programmer, or we may only >be causing more confusion than we can handle. Exactly. HEM =3D Hacker Event Model. However it should probably only be documented as such. I don't like the idea of creating a whole new event model for this kind of stuff, because then Win32::GUI sources would become even more confusing to read :). Like I said many times, this is just for the hackers who want something that Win32::GUI's current event models do not support (like me) and is only a preliminary experiment. It seems to work, and seems to work very well. Whether it'll screw everything else up is yet to be seen, but it can easilly be taken out if it causes too many problems. Hey, that's what a CVS version is for. Does typing "$win->Hook(132,\&hello)" class as an "*explicit* request"? :) Regards, Steve |
From: Aldo C. <da...@pe...> - 2003-12-05 15:02:59
|
Stephen Pick wrote: > Does typing "$win->Hook(132,\&hello)" class as an "*explicit* request"? > :) Steve, you have good points. I agree wholeheartedly with you, so what more can I say? go for it :-) just a quick note: the NEM, in its present state, is not really useable. I have different plans for the future (I already coded something in my codebase, but as I said it's not fully functional yet); that said, just be prepared for something completely different once I've ironed out all the design stuff and I will disclose my new codebase (which will probably be Win32::GUI 1.00 (at least! :-)). if I find the time, I would like to write a (very) technical article about all this Event Model stuff on Win32::GUI, so that you can see where we are (supposedly) going. keep on working on the current release (.665-Fix) for now, and we'll sort out how to re-integrate all the good things in the upcoming 1.00. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; |
From: Glenn L. <pe...@ne...> - 2003-12-05 16:56:38
|
On approximately 12/5/2003 7:00 AM, came the following characters from the keyboard of Aldo Calpini: > Stephen Pick wrote: > >>Does typing "$win->Hook(132,\&hello)" class as an "*explicit* request"? >>:) > > > Steve, you have good points. I agree wholeheartedly with you, so what > more can I say? go for it :-) > > just a quick note: the NEM, in its present state, is not really > useable. I have different plans for the future (I already coded > something in my codebase, but as I said it's not fully functional > yet); that said, just be prepared for something completely different > once I've ironed out all the design stuff and I will disclose my > new codebase (which will probably be Win32::GUI 1.00 (at least! :-)). > > if I find the time, I would like to write a (very) technical article > about all this Event Model stuff on Win32::GUI, so that you can see > where we are (supposedly) going. keep on working on the current > release (.665-Fix) for now, and we'll sort out how to re-integrate > all the good things in the upcoming 1.00. All this sounds good. I was a little surprised your hooks are done after regular Win32::GUI processing, but I guess they are still done before/instead of DefWindowProc, so that makes sense to me. Is there any reason HEM cannot be used in conjunction with the old event model? -- 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. |
From: Steve P. <st...@ba...> - 2003-12-05 18:16:13
|
Hi, > Is there any reason HEM cannot be used in conjunction with the old event > model? Not that I can think of. I just forgot to add it to that bit. My hooks arent real Win32 hooks at all, as you know, and I put the processing of them after the NEM stuff so as to make it more difficult to screw up normal functionality. If you want to handle something already handled by NEM, I recommend you use NEM. If you must use "HEM" then things will probably still work as expected, since it's likely you will override changes made by the NEM handlers. Steve ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...> To: "Aldo Calpini" <da...@pe...> Cc: <per...@li...>; "Stephen Pick" <Ste...@uc...> Sent: Friday, December 05, 2003 4:42 PM Subject: Re: [perl-win32-gui-hackers] Proposition for NEM > On approximately 12/5/2003 7:00 AM, came the following characters from > the keyboard of Aldo Calpini: > > > Stephen Pick wrote: > > > >>Does typing "$win->Hook(132,\&hello)" class as an "*explicit* request"? > >>:) > > > > > > Steve, you have good points. I agree wholeheartedly with you, so what > > more can I say? go for it :-) > > > > just a quick note: the NEM, in its present state, is not really > > useable. I have different plans for the future (I already coded > > something in my codebase, but as I said it's not fully functional > > yet); that said, just be prepared for something completely different > > once I've ironed out all the design stuff and I will disclose my > > new codebase (which will probably be Win32::GUI 1.00 (at least! :-)). > > > > if I find the time, I would like to write a (very) technical article > > about all this Event Model stuff on Win32::GUI, so that you can see > > where we are (supposedly) going. keep on working on the current > > release (.665-Fix) for now, and we'll sort out how to re-integrate > > all the good things in the upcoming 1.00. > > All this sounds good. I was a little surprised your hooks are done > after regular Win32::GUI processing, but I guess they are still done > before/instead of DefWindowProc, so that makes sense to me. > > Is there any reason HEM cannot be used in conjunction with the old event > model? > > -- > 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. > > > > ------------------------------------------------------- > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers > |
From: Glenn L. <pe...@ne...> - 2003-12-05 21:12:31
|
On approximately 12/5/2003 10:19 AM, came the following characters from the keyboard of Steve Pick: > Hi, > >>Is there any reason HEM cannot be used in conjunction with the old event >>model? > > Not that I can think of. I just forgot to add it to that bit. I'd find it more likely useful to me in the short term, if it were added to the old event model ("OEM" ??? Horrible acronym, but we need something). > My hooks arent > real Win32 hooks at all, as you know, and I put the processing of them after > the NEM stuff so as to make it more difficult to screw up normal > functionality. If you want to handle something already handled by NEM, I > recommend you use NEM. If you must use "HEM" then things will probably still > work as expected, since it's likely you will override changes made by the > NEM handlers. Yes, this makes more sense the longer I think about it, and the more you explain it! Thanks. -- 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. |