Mouse messages contain the grid number of the grid with mouse focus when the event was detected. The grid with mouse focus is generally the grid the mouse cursor is in, except in the following situation. When the state of the mouse buttons changes from no buttons depressed to one or more depressed, the grid that contains the mouse cursor grabs mouse focus and keeps it until all mouse buttons are released. v0,v1,v2,v3 contain x,y,state,time.
x,y contain the local coordinates of the mouse cursor in grid at the time the mouse event was detected. x,y may indicate a mouse cursor position outside the grid if mouse focus has been grabbed.
Bit 00 - 03 : Button # causing event (MouseDown and MouseUp only )
Bit 04 - 06 : # of clicks (MouseDown only)
Bit 07 : 1 if grid has mouse focus
Bit 08 - 15 : Reserved
Bit 16 - 23 : Keyboard "mode" keys (16=Shift, 17=Control, 18=Alt)
Bit 24 - 31 : Up/Down image of up to 8 mouse buttons (1 = down)
Bit 00 - 03 : Button #: None=0 : Left=1 : Center=2 : Right=3...
Bit 16 = 1 : Shift key is down
Bit 17 = 1 : Control key is down
Bit 18 = 1 : Alt key is down
Bit 24 = 1 : Left button is down
Bit 25 = 1 : Center button is down
Bit 26 = 1 : Right button is down
Bit 27 - 31 : Other buttons down (assignments not guaranteed)
time contains the system time that the keyboard event was detected. time is not related to time of day. time is a free running millisecond timer that computer systems usually initialize to zero when they start.
mouse message algorithm
Your program doesn't receive a mouse message for every change in mouse position the system detects. When your task is too busy to process messages, GraphicsDesigner does not flood your message queue with #MouseMove messages. Instead, GraphicsDesigner adds #MouseMove messages to the message queue only when the message queue is empty. All other mouse messages, including #MouseDrag , are added to the message queue whether it has contents or not.
This method of generating mouse messages is best for most programs, and avoids overflowing your message queue with superfluous #MouseMove messages. In rare instances, however, your program may want to receive every mouse message. To achieve high-speed mouse position tracking, programs must access the message queue often. This keeps the message queue empty and assures new mouse messages are put in the queue immediately. Programs can achieve high-speed tracking by responding to messages quickly and returning to the main message loop, or by processing them often with:
XgrProcessMessages(0) returns immediately if there are no messages in the message queue and the mouse state has not changed. Otherwise it processes one message, then returns.
Be careful with this technique, however. If your program processes a new #MouseMove message while it's in the middle of processing the previous #MouseMove , will your program produce adverse effects when it finishes processing the earlier #MouseMove ?