Hi,
Am I really confused, or are accelerators really, really broken? Some
reasonings that have led me to the conclusion accelerators are really,
really broken include:
(1) Win32::GUI::AcceleratorTable pushes a global variable $id for each
of the keystrokes in the accelerator table, resulting in any accelerated
keystroke for that table having the same "cmd" value of $id ... whatever
it happens to be at the time of the call. It would be extremely hard to
distinguish between keystrokes, when the WM_COMMAND message is received,
the cmd field is what gets supplied to identify the accelarator's
command, so any of the keystrokes would seem to do the same thing....
but, read on...
(2) Win32::GUI::AcceleratorTable seems to keep a global counter of how
many accelerators have ever been defined, which gets incremented in the
loop.... but not used. Perhaps this is the value that should be pushed
instead of the global variable $id...
(3) The destruction of a global variable $Win32::GUI::AcceleratorTable
if it exists, seems to be just a misleading activity, probably leftover
code. It seems to imply that there can only be one accelerator table
defined, but in fact, $Win32::GUI::AcceleratorTable is never set, only
destroyed.
(4) When the WM_COMMAND comes in, the command code is known, and the
accelerator table could be looked up via perlud.hAcc from the current
active window. However, insteald the command code is looked up in the
otherwise unreferenced hash "Win32::GUI::Accelerators". It would seem
that the lookup process would first need to discover the perlcs{-accel}
value, to find the hash in which the accelerators were defined, and then
look in that hash to find the actual name of the command that is assigned.
(5) This is all based on command names, so it seems that there is no
code to support the New Event Model.
--
Glenn
=====
Not everything that is counted counts,
and not everything that counts can be counted.
-- A. Einstein
