Steve Pick wrote:
> Hello,
>
> Here's a nice idea:
mmm. that's nice, but not as nice as it may seem. I see many problems
with this one:
1) you can't easily (I mean, without a lot of effort) intercept all
kind of messages. this is due to the rather complex nature of
the Windows messaging system. just to make an example, WM_MOUSEMOVE
messages are always sent to the window itself (eg. the handle
of the window when the mouse moves over an *empty area* of the
window, the handle of a button when the mouse moves over a button
contained in the window). a click on the button, on the other
hand, is always sent to the *container* window in the form of
a WM_COMMAND message, so you won't get it attaching a "hook"
to the button itself. that's rather confusing. and that's also
why most of the complexity of Win32::GUI is there, otherwise it
would be a really linear and simple module.
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.
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.
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.
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
- is absolutely impossible to document it properly, and this will
be an inevitable cause of frustration to the end user
- it may cause "cargo-cult" programming that in the long run
will do more harm than good (see the experience with -style)
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). 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.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
