On approximately 12/10/2003 2:44 AM, came the following characters from
the keyboard of Stephen Pick:
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.
OK, I figured you must be looking at an older version to notice the acc=
difference.
You mention that messages are queued and combined.
I know that mouse movement operations are "combined", the Windows
documention points out that recording a separate message for every pixel
of motion would consume great length of queue, to little avail... if the
program isn't watching the mouse cursor position for some particular
reason, all it generally cares about is that it moved, and where it
wound up.
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?
I'm not saying that; I'm saying that I don't know the extent of the
types of operations that Windows might decide to queue and combine; I
wouldn't expect that mouse down would be combinable, but then again I
wouldn't have expected that the IBM PC keyboard design would generate
repeated Key Down messages for held keys, either. Seems like one, when
you actually push it down, would suffice, any actions that should result
from holding it would seem to be possible to generate in software, not
hardware. But I think the hardware generates multiples. I'm not at all
sure what Windows does with them, but it seems that "programming the
keyboard repeat rate" is still the way that Windows changes the repeat
rate for keystrokes. So whether either the "combined" queue effect, or
the "key down repeat" technique is used for "mouse down" I have no clue.
But I thought I'd mention it, to get you thinking about broad
possibilities of what you might not see in the code.
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*.
But I think if you use Win32::API to call call PeekMessage with the
PM_REMOVE set, that you may not get the repeated behavior... me thinks
the bug is inside DoEvents, somehow.... it just hit me... maybe the
PM_REMOVE constant is wrong? (Pure speculation here, but something is
wrong, and it isn't obvious.)
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 haven't noticed those before. So much to learn about Windows API.
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.
I wondered that myself, and convinced myself that no, that probably
wasn't the case. By tracing and monitoring messages received in
DoEvents and Dialog, and tracing and monitoring the calls to
DefWindowProc, and observing what happens in the textfield as I type, I
have concluded that the Key Down message is received once, but the Key
Up message is received and processed multiple times to contribute to the
problem. This makes me think it might be some sort of reentrancy
problem, or that I am very, very confused. At this point, I'm open to
suggestions, and have given up on debugging that issue, but am avoiding
writing code that uses DoEvents until (1) I screw up my courage to dive
into debugging it having learned some new thing about Windows API (2)
someone else fixes it.
--
Glenn -- http://nevcal.com/
===========================
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
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html
So that's profit of over 400% of investment... with a bit more
investment in Windows technology, particularly in the area of
reliability, the profit percentage might go down, but so might the bugs
and security problems? Seems like it would be a reasonable tradeoff.
WalMart earnings are 3.4% of investment.
