RE: [perl-win32-gui-hackers] Proposition for NEM

[Stephen P. <Ste...@uc...>]

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