Hi Aldo,
The next two paragraphs are kind of "pie in the sky" or "dream
concepts"... but after them are some bug reports...
Glad to see you back and working on Win32::GUI. I've been contemplating
either (1) trying to fix and enhance it myself or (2) replacing it
with something perhaps simpler, slower, and yet more general....
computers are fast these days, so perl code vs C code might be less
significant... I thought about maybe doing something like allowing
_every possible_ event to be intercepted, using something similar to
your new event model... and just defining those events for which user
actions are desire perhaps even via the standard Windows constants....
and anything not handled by the user would go to the default windows
handler. It might be nice to have 2 functions, one called before the
default windows handler, and one after, and also a flag saying the
default window handler should be skipped. Or maybe it would be simpler
to provide an API to invoke the default window handler from the user
handler... and make the user responsible for calling the default
handler, if desired, from those user defined event handlers.
However, since the new event model seems to have much missing
functionality in the 0.0.665 release, trying to get my own head around
it was difficult, and yet I really didn't want to try to write something
from scratch either.
Attached are some messages from a couple months ago showing problems
mostly in accelerator key support, both in the old and new event models.
I must have accelerator key support in my next major project, so I
must fix them (or replace Win32::GUI) if you don't....
I tried to use the new event model, with dynamically generated menus,
and couldn't.... it seemed the events never got triggered. Perhaps
something is missing there, or perhaps I didn't understand something.
I've sort of abandoned that code, but if you know you've fixed something
in that area, or implemented more of the new event model, I'd like to
try it again.
I'd like to convert fully to the new event model, or something similar.
Stuart Arnold <[EMAIL PROTECTED]> appears to be new to Win32::GUI
and has had lots of questions recently. One comment he made was about
the use of the GWL_USERDATA field by Win32::GUI. While I initially
thought it was quite reasonable for Win32::GUI to use this hook (one of
the few provided by Windows API) for its own purposes, it would be nice
to provide a replacement.... or, this hit me later... instead of having
Win32::GUI use GWL_USERDATA to look up the Win32::GUI data structures
given a window handle, it would be possible to just make a side hash
structure, indexed by window handle, that would contain the Win32::GUI
data.... this would leave GWL_USERDATA free for user data, as Stuart
desired....
--
Glenn
=====
If the grass is greener on the other side of the fence,
try taking better care of your own side. -- Unknown
--- Begin Message ---
Hi,
I have a program that uses Win32::GUI, and in several places, it uses a
DoEvents loop, and text boxes processed by that DoEvents loop seem to
result in doubled characters. I don't recall that happening in earlier
versions of Win32::GUI, does anyone else?
So I recompiled Win32::GUI with several of the debug #defines in place,
and started reading Win32::GUI code. I've not been a creater of Windows
programs before Win32::GUI, so I'm not real familiar with the Windows
API, but it is documented, sort of. So I figure debugging this will be
a good learning experience to get me somewhat familiar with the Windows
API, intensely familiar with Win32::GUI, somewhat familiar with XS, and
perhaps able to contribute to its development.
So first I had to figure out the message loop(s), since that is where
all the action happens first. I notice that there is a discrepancy
between the message handling in Win32::GUI::Dialog vs
Win32::GUI::DoEvents vs Win32::GUI::DoModal.
The message handling logic flow in all three procedures is very similar
(and perhaps should be abstracted into a single procedure for ease of
maintenance... maybe it wasn't because this is XS? I don't speak XS
well, either)
I notice that the logic flow includes 3 local variables: perlud,
fIsDialog, and acc, that I wish to discuss here. Before setting perlud,
fIsDialog and acc are both set to zero. After calculated perlud, if it
validates, then fIsDialog is extracted from the dwPlStyle field. In
DoEvents alone, the acc variable is also set in this block. In Dialog
and DoModal, the local variable "acc" is not set, hence being left at
NULL. However, the logic after that, identical in all three places, has
two tests for (acc != NULL) which will never be true in Dialog or DoModal.
It would appear that this could be a reason for accelerator keys not
functioning in many circumstances?
Or is it just extraneous code, and a bug in DoEvents?
N.B. It seems that the code in Win32::GUI 0.0.558 was more complex (also
checking a -accel key) for calculating the local variable "acc", but it
did exist in both of them. DoModal didn't exist in 558, of course.
--
Glenn
=====
Not everything that is counted counts,
and not everything that counts can be counted.
-- A. Einstein
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--- End Message ---
--- Begin Message ---
Hi,
Re: Win32::GUI 0.0.665
It appears that the code to implement accelerators doesn't even exist
for the New Event Model. A DoEvent_NEM_Acc function is mentioned in
some commented out code, but the function doesn't exist in the
distributed source code.
--
Glenn
=====
Not everything that is counted counts,
and not everything that counts can be counted.
-- A. Einstein
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--- End Message ---
--- Begin Message ---
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
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
--- End Message ---
