RE: [perl-win32-gui-hackers] DoEvents() bug.

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

Hi Glenn,

I admit I was looking at a slightly older version of the CVS (since I
can't get access to CVS at work anymore), but most things are the same
from what I checked at home.

You mention that messages are queued and combined. I'd not class myself
as highly experienced with Windows messaging, but the PeekMessage call
in DoEvents specifies "PM_REMOVE" to delete the message it captures from
the queue, so this message should be removed. Are you saying that when
one uses PeekMessage, WM_LBUTTONDOWN messages will be continually
generated by windows, even if PM_REMOVE is specified?

The problem is that if GetMessage is called when the mouse button is
down, the WM_LBUTTONDOWN message is received, and if you then call
GetMessage again, no message is received. However if you call
PeekMessage with PM_REMOVE set you get the WM_LBUTTONDOWN message, then
if you call PeekMessage again with PM_REMOVE set, you get the
WM_LBUTTONDOWN message a second time, then a third time, over and over
*until another event occurs such as WM_PAINT or WM_MOUSEMOVE*.

There is a function (WaitForInputIdle)that "waits until the specified
process is waiting for user input with no input pending, or until the
time-out interval has elapsed" and a flag for PeekMessage (PM_NOYIELD)
that "prevents the system from releasing any thread that is waiting for
the caller to go idle"

Perhaps these might fix the problem?

I'm pretty sure that the textfield character-doubling could be to do
with the fact that one gets both WM_KEYDOWN and WM_KEYUP messages when a
key is pressed, and a character is produced for both for some reason. I
will muck about with the CVS version (which I can now obtain at work
thanks to my cute PC-Anywhere-Via-HTTP-Proxy thingy :) ) and see if I
can find a way to solve the problem.

Steve

-----Original Message-----
From: Glenn Linderman [mailto:pe...@ne...]
Sent: 09 December 2003 19:03
To: Stephen Pick
Cc: Win32 GUI Hackers
Subject: Re: [perl-win32-gui-hackers] DoEvents() bug.


On approximately 12/9/2003 2:59 AM, came the following characters from
the keyboard of Stephen Pick:

> Hi all.
>=20
> When I do this:
>=20
> Win32::GUI::Dialog()
>=20
> I receive all my events like WM_LBUTTONDOWN (-onMouseDown) once, as
> should happen.
>=20
> When I do this:
>=20
> while(1) {
> 	Win32::GUI::DoEvents()
> 	print "Loop!\n";
> }
>=20
> I get endless calls to my event handler so long as the mouse button is
> down. I have NO idea why. Must be some kind of windows internal thing.

Certain Windows messages are "queued and combined" if you are not=20
looking, but the more often you look, the more often you get them....  I

could say if MouseDown is one of those, off hand.

I have noticed that a difference between Dialog() and DoEvents() is that

if used to process a dialog box containing a text box, that the former=20
responds normally, but the latter generally doubles the characters=20
received by the text box.  One difference in my situation is that I was=20
  calling DoEvents() from an event, and that might cause some sort of=20
reentrancy problem, but I couldn't understand what it would be if it is=20
such.  I gave up and restructured my code to use Dialog() only.

> Additionally, since the code for DoEvents() and Dialog() is
practically
> identical except that DoEvents uses PeekMessage and Dialog uses
> GetMessage, I copied both into seperate files and took a look at them
in
> WinMerge. Interesting. Dialog does ENTER; SAVETMPS; before doing
> GetMessage and FREETMPS; LEAVE; at the end of it's while() loop.
> DoEvents() doesn't do this.=20

This is because Dialog is "long-running" and needs to be sure to do Perl

temporary variable management, and DoEvents returns to Perl more often,=20
so can let Perl do the temporary variable management.  I think.

> Also, DoEvents has the line "acc =3D
> perlud->hAcc;", and Dialog() DOESNT have that. Dialog() does a
> comparison on acc (acc !=3D NULL) in the next few lines just like
DoEvents
> does, but this comparison will always yield false in Dialog().

I think that was one of the lines I "fixed" in making accelerator keys=20
work.  If not, it should have been.  What version of source are you=20
looking at?

> So. I don't have a compiler here but this is weird. Surely these
> functions should be identical but for the change from GetMessage to
> PeekMessage. Moreover, if these functions should be identical then why
> write the same code for both when a simple function that does either
> PeekMessage or GetMessage depending on an argument would remove a lot
of
> redundant code, for example the new function checkEvents(hwnd,
> peekmessage) would do the current Dialog() code with PeekMessage if
> peekmessage was set to 1, otherwise it'd do GetMessage, and the
Dialog()
> and DoEvents() methods could be truncated to:

Well, the exit condition is different too, not just the call to=20
GetMessage vs PeekMessage.  But that also could be based on the=20
"argument".  I agree there is much redundant code there, also see
DoModal.

>=20
> DWORD
> Dialog(hwnd=3DNULL)
> 	HWND hwnd
> CODE:
> 	RETVAL =3D checkEvents(hwnd,0);
> OUTPUT:
> 	RETVAL
>=20
> DWORD
> DoEvents(hwnd=3DNULL)
> 	HWND hwnd
> CODE:
> 	RETVAL =3D checkEvents(hwnd,1);
> OUTPUT:
> 	RETVAL
>=20
>=20
>=20
> Steve
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>=20
>=20

--=20
Glenn -- http://nevcal.com/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26

  billion on revenue of $2.81 billion.
  --from Reuters via=20
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more=20
investment in Windows technology, particularly in the area of=20
reliability, the profit percentage might go down, but so might the bugs=20
and security problems?  Seems like it would be a reasonable tradeoff.=20
WalMart earnings are 3.4% of investment.