100% Bug Free - 0% Logic
-
The below code was written by two of my team mates in two different projects. Below code in MFC.
...::OnMouseMove(...)
{
CRect rc; GetClientRect(rc);
ClientToScreen(rc);
POINT pt; GetCursorPos(&pt);
if (rc.PtInRect(pt))
{
/* Proceed */
}
/* return */
}What they are tryin is, checking the mouse pointer is over the window in OnMouseMove Handler... What to say?...I think one should Cut and Copy the above logic!!!..
Do your Duty and Don't expect the Result
Rate this Post, if I helped You -
The below code was written by two of my team mates in two different projects. Below code in MFC.
...::OnMouseMove(...)
{
CRect rc; GetClientRect(rc);
ClientToScreen(rc);
POINT pt; GetCursorPos(&pt);
if (rc.PtInRect(pt))
{
/* Proceed */
}
/* return */
}What they are tryin is, checking the mouse pointer is over the window in OnMouseMove Handler... What to say?...I think one should Cut and Copy the above logic!!!..
Do your Duty and Don't expect the Result
Rate this Post, if I helped YouBrilliant piece of being sure!! :laugh:
-
The below code was written by two of my team mates in two different projects. Below code in MFC.
...::OnMouseMove(...)
{
CRect rc; GetClientRect(rc);
ClientToScreen(rc);
POINT pt; GetCursorPos(&pt);
if (rc.PtInRect(pt))
{
/* Proceed */
}
/* return */
}What they are tryin is, checking the mouse pointer is over the window in OnMouseMove Handler... What to say?...I think one should Cut and Copy the above logic!!!..
Do your Duty and Don't expect the Result
Rate this Post, if I helped YouCheck whether they've used
SetCaptureanywhere. If the mouse is captured, you will get mouse event messages outside the window's client rectangle. Also, note thatGetCursorPostells you the current position - aWM_MOUSEMOVEmessage tells you that the mouse moved when captured or when over the window at some point in the past. Perhaps they were trying to filter out old events? This would only be a problem if the application isn't very responsive to window messages, however. If you want to know the cursor position when the message was generated, that appears in theWM_MOUSEMOVEmessage'slParamparameter. This is actually relative to the client rectangle already, soClientToScreenis not required. MFC'sOnMouseMovefunction extracts thelParammessage parameter to thepointparameter. Do note however that Windows limits the rate at which it sendsWM_MOUSEMOVEmessages so that applications aren't overwhelmed, if the application is busy. You used to be able to see this effect in Windows Paint if you moved the mouse very rapidly while drawing - the line would be in lots of straight segments, rather than being smooth - but modern PCs are well up to the demands of Paint, so you don't see it any more. (Personally I would useScreenToClienton the cursor's location and then use client rectangle-relative co-ordinates throughout, rather than converting the other way).Stability. What an interesting concept. -- Chris Maunder
-
Check whether they've used
SetCaptureanywhere. If the mouse is captured, you will get mouse event messages outside the window's client rectangle. Also, note thatGetCursorPostells you the current position - aWM_MOUSEMOVEmessage tells you that the mouse moved when captured or when over the window at some point in the past. Perhaps they were trying to filter out old events? This would only be a problem if the application isn't very responsive to window messages, however. If you want to know the cursor position when the message was generated, that appears in theWM_MOUSEMOVEmessage'slParamparameter. This is actually relative to the client rectangle already, soClientToScreenis not required. MFC'sOnMouseMovefunction extracts thelParammessage parameter to thepointparameter. Do note however that Windows limits the rate at which it sendsWM_MOUSEMOVEmessages so that applications aren't overwhelmed, if the application is busy. You used to be able to see this effect in Windows Paint if you moved the mouse very rapidly while drawing - the line would be in lots of straight segments, rather than being smooth - but modern PCs are well up to the demands of Paint, so you don't see it any more. (Personally I would useScreenToClienton the cursor's location and then use client rectangle-relative co-ordinates throughout, rather than converting the other way).Stability. What an interesting concept. -- Chris Maunder
Yeah, that's exactly what I was thinking as I read the code. I wonder what the truth of the matter is....
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Check whether they've used
SetCaptureanywhere. If the mouse is captured, you will get mouse event messages outside the window's client rectangle. Also, note thatGetCursorPostells you the current position - aWM_MOUSEMOVEmessage tells you that the mouse moved when captured or when over the window at some point in the past. Perhaps they were trying to filter out old events? This would only be a problem if the application isn't very responsive to window messages, however. If you want to know the cursor position when the message was generated, that appears in theWM_MOUSEMOVEmessage'slParamparameter. This is actually relative to the client rectangle already, soClientToScreenis not required. MFC'sOnMouseMovefunction extracts thelParammessage parameter to thepointparameter. Do note however that Windows limits the rate at which it sendsWM_MOUSEMOVEmessages so that applications aren't overwhelmed, if the application is busy. You used to be able to see this effect in Windows Paint if you moved the mouse very rapidly while drawing - the line would be in lots of straight segments, rather than being smooth - but modern PCs are well up to the demands of Paint, so you don't see it any more. (Personally I would useScreenToClienton the cursor's location and then use client rectangle-relative co-ordinates throughout, rather than converting the other way).Stability. What an interesting concept. -- Chris Maunder
Mike Dimmick wrote:
Check whether they've used SetCapture anywhere
No they didn't use it. Actually what the requirement is, 1) for the 1st project to change the dialog apperiance while the mouse hovers in it. That is the dialog will be in small size, but if the mouse hovers then the size will be enlarged. 2) for the 2nd project, it is a custom button class, to give the XP effect they are catching WM_MOUSEMOVE messsage and redraw the button accordingly.
Do your Duty and Don't expect the Result
Rate this Post, if I helped You -
Yeah, that's exactly what I was thinking as I read the code. I wonder what the truth of the matter is....
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
I wonder what the truth of the matter is....
Do your Duty and Don't expect the Result
Rate this Post, if I helped You -
The below code was written by two of my team mates in two different projects. Below code in MFC.
...::OnMouseMove(...)
{
CRect rc; GetClientRect(rc);
ClientToScreen(rc);
POINT pt; GetCursorPos(&pt);
if (rc.PtInRect(pt))
{
/* Proceed */
}
/* return */
}What they are tryin is, checking the mouse pointer is over the window in OnMouseMove Handler... What to say?...I think one should Cut and Copy the above logic!!!..
Do your Duty and Don't expect the Result
Rate this Post, if I helped YouParthi_Appu wrote:
...::OnMouseMove(...){
and just say
return;That would enhance performance too by not creating objects. Isn't it? :)Vasudevan Deepak Kumar Personal Homepage Tech Gossips