On approximately 3/14/2004 8:00 PM, came the following characters from
the keyboard of Glenn Linderman:
I was working on trying to transform the WM_NOTIFYICON code from the
standard message loop to work in the NEM message loop, and allow
AddNotifyIcon to take -onClick -onRightClick and -events parameters,
with the -events allowing Click and RightClick. Then I noticed
MousEvent in the default case, I guess we'd need -onMouseEvent for that?
I haven't really figured out the "correct" data structures for where to
put the sub refs for -onClick etc. so that they can be found and called
via DoEvent_NEM... that was what I'd hoped to figure out tomorrow or so.
Or else to invent a new DoEvent_NEM type function that accepts the sub
ref as a parameter, and does all the standard Perl interfacing.
Depending on what I could figure out. I'd rather not hold anything up,
but I need NotifyIcon support if I'm going to use NEM.
OK, I've figured out a few things about NEM event processing. There is
a hash with all the events, by name, hung off the window structure.
And, there is a bitfield, which apparently is an optimization to avoid
checking the hash to discover that the event name wasn't registered.
So the set of #defines named PERLWIN32GUI_NEM_* are mostly to do with
that bit field. The DEACTIVATE, ACTIVATE, TERMINATE, MINIMIZE,
MAXIMIZE, and RESIZE seem to have two bits set... but no special
consideration is given to that in the code, as far as I can tell. So if
any of these are defined, it could cause all of the others to be looked
up in the hash? As well as SCROLL, and one of the ones from MOUSEMOVE
to CLICK?
Maybe it is "known" that MOUSEMOVE->CLICK are never used for the same
types of windows as DEACTIVATE->RESIZE? But if that is the case,
there'd be no need for the 0x10000000 bit to be set in
DEACTIVATE->RESIZE... simple reuse of the lower bits would be fine...
and then defining a handler for one of these wouldn't cause hash to be
checked for all of them!
And maybe SCROLL was added later, not noticing that it overlapped with
the bit in DEACTIVATE->RESIZE?
Does anyone have an explanation for this?
I'm planning to add NOTIFYICON to the list of bits, and set it in the
flags words if any of NotifyIcon Click, RightClick, or MouseEvent
handlers are defined. So hence if any of this "bundle" are defined, all
of them will pay the price of checking the hash for existance.
And it looks like to support Accelerator keys, I'm going to need to add
ACCELERATOR to the list, which will use the last available bit... and
"bundle" all the accelerator keys under that bit.
I wonder if there are other items that could be "bundled" to save bits?
MOUSEDOWN MOUSEUP ? CLICK DBLCLICK ? GOTFOCUS LOSTFOCUS ?
Hmmm. Surprised there is no RIGHTCLICK or DBLRIGHTCLICK on anything in
these lists!... that'd make a nice bundle too. Doesn't NEM support
RightClicking?
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
