For the state of the mouse, I specifically used a global variable storage, and the variable structure is as follows:
static struct MOUSE_EVENT_STRUCT {// buffer status BOOL DblClicked; // Double-effective number BOOL LButtonWasUp; // release button once BOOL RButtonWasUp; // right once release BOOL LButtonWasDown; // button is pressed once BOOL RButtonWasDown; // Right click on the short nmousewheel; // Roller offset // Current status int x; // Current mouse x coordinate int y; // Current mouse y coordinate BOOL LBUTTON; // Left button BOOL RBUTTON; / / Right click Status Bool mbutton; // middle key status};
The button message is obtained directly from the message loop. WM_CHAR. Because the RPG online game I plan to do is not concerned about the real-time state of the keyboard, I only need to know what the button has been pressed. WM_CHAR gets Keycode from the WndProc process, passed to CGAME, and then passed to CGAME to CDESKTOP Current Focus Control.
Then start the window of the window on the mouse.
The window itself has an attribute: ismove (); this property determines whether the window can move and respond to the mouse. When it returns True, the form is judged by the mouse coordinate.
IF (Form is a standard rectangle) {if (mouse in drag response zone) starts drag form} else {if (mouse is not in a child control) to be dragged window body. }
About dragging the response area
Look at the picture below:
You can see a form, the title bar is written: debug status. If I define the mouse within the red rectangle, I need to judge whether the mouse coordinate is within this rectangle and the left button is pressed.
This red rectangle is defined by cskin reading the skin. Its LEFT, TOP, RIGHT correspond to an offset of the form actual LEFT, TOP, RIGHT, and Height is a fixed value indicating the height of the rectangle.
First, CDESKTOP is passed to a variable pointer to a response message structure, and then returned by the response to the mouse, the keyboard information, and the cdesktop processes some operations (focus conversion, coordinate shift, etc.) according to the return information, and then the final message The result is returned to the CGAME to process the game logic event.
CDESktop care information is as follows:
The window: (if not the current window, set to the current window, if you are null, ignore.)
Responsive control: (if not the current activation control, set to activate the control, if null, ignore.)
Response event ID: (for example M_Click, M_LBTNDOWN, M_RBTNDOWN .., etc.)
Response process function: a function pointer
My idea is to use a function pointer to deal with the response message. Each CWIN saves a single message processing function pointer address. If it is not an empty address, the response is received after the response is received to perform the logic event of the game. Put the logical event handler of the game in a class, declare to static for CGAME call, which looks relatively clear.
I think this approach should be close to the Windows event drive mechanism, a little callback function.
