• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 284
  • Last Modified:

Problem with mouse coordinates to screen mapping? (I think)

I'm using the following code to draw two lines which intersect at the mouse location:

      if (m_bCrossHairEnabled)
      {
            CPen penYellow;
            penYellow.CreatePen(PS_SOLID, 1, RGB(255,255,0) );

            CPen* pOldPen = (CPen*)pDC->SelectObject(&penYellow);

            // vertical line
            pDC->MoveTo(m_pMouseLoc->x+m_iPenWidth, m_pCenterViewRect->top);
            pDC->LineTo(m_pMouseLoc->x+m_iPenWidth, m_pCenterViewRect->bottom);

            // horizontal line
            pDC->MoveTo(m_pCenterViewRect->left+m_iPenWidth, m_pMouseLoc->y);
            pDC->LineTo(m_pCenterViewRect->right-m_iPenWidth, m_pMouseLoc->y);
      }

-----------

This code is called after each WM_MOUSEMOVE.

I roll the mouse around and when it is within the bounds of m_pCenterViewRect, these two lines are drawn to intersect the mouse.

Anyway,  the problem I'm having is with regards to the horizontal line. While I move my mouse around, the vertical line redraws and follows the horizontal movement of the mouse as it should. But the horizontal line moves in the opposite direction of the vertical movement of my mouse. I move the mouse up, the line is drawn farther down. I move the mouse down, the line is drawn further up.  Backward! I've watched the variables closely, m_pCenterViewRect = CRect(300,300,700,700) -  previously in the code I use pDC->Rectangle(m_pCenterViewRect); to draw the empty rectangle, and this work just fine. If I roll my mouse into it just inside the top left corner for example, and break into the code, I see the mouse point is point(303,,303)  - so my point/rect values are correct.  I then watch  as the LineTo code executes, and this is what would be run:

                pDC->Rectangle(CRect(300,300,700,700));

                //...

                // horizontal line
            pDC->MoveTo(301, 303);
            pDC->LineTo(699, 303);

at which point I see the line get drawn, but it is clearly not at the vertical coordinate Y=303.. It's more like Y=697.

What am I doing wrong here?

thanks!
-Paul

0
PMH4514
Asked:
PMH4514
  • 11
  • 5
  • 3
  • +1
1 Solution
 
AlexFMCommented:
Looks too complicated. WM_MOUSEMOVE message contains mouse coordinates. I don't see them in this code fragment.
0
 
SteHCommented:
Are any mappings activated in any device context?
0
 
PMH4514Author Commented:
AlexFm - what looks complicated? m_pMouseLoc is a member variable which is populated with the mouse coordinates when the WM_MOUSEMOVE message is triggered. the values in the CPoint object referenced by m_pMouseLoc are correct.

SteH : I'm not sure. I don't believe so. Could you show me an example?
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
AlexFMCommented:
What is m_pCenterViewRect? If m_pMouseLoc is mouse point, code should look like this:

          // vertical line
          pDC->MoveTo(m_pMouseLoc->x, m_pMouseLoc->y - n);
          pDC->MoveTo(m_pMouseLoc->x, m_pMouseLoc->y + n);

          // horizontal line
          pDC->MoveTo(m_pMouseLoc->x - n, m_pMouseLoc->y);
          pDC->MoveTo(m_pMouseLoc->x + n, m_pMouseLoc->y);
   
n is cross size.
0
 
PMH4514Author Commented:
oh.. interesting.. moving from the point outwards, rather than from the rect boundry across.

but - why only MoveTo? what about LineTo? I'm assuming that's a typo on your part. Can you do LineTo w/o a corresponding MoveTo?


0
 
AlexFMCommented:
Yes, this is typo.

          // vertical line
          pDC->MoveTo(m_pMouseLoc->x, m_pMouseLoc->y - n);
          pDC->LineTo(m_pMouseLoc->x, m_pMouseLoc->y + n);

          // horizontal line
          pDC->MoveTo(m_pMouseLoc->x - n, m_pMouseLoc->y);
          pDC->LineTo(m_pMouseLoc->x + n, m_pMouseLoc->y);
   
0
 
PMH4514Author Commented:
>> Yes, this is typo.
yup.. gotcha.. this still doesn't work though.   With your code I have to calculate n because it will be the distance from the mouse to the edge, while the cross size itself is constant (400 pixels each way) - the point at which they intersect is the mouse location.. but, I did try your code, calculating the value for n, the the result is exactly the same.

I wonder if somehow what I'm seeing isn't flipped vertically.. this camera I'm using is in a breadboard phase, and while there is "up", there is not way for me to visually cue what is up and what is down.. maybe the lines are drawn correctly, but then my entire image is being flipped..

that gives me an idea..  be back later..

:)

-Paul
0
 
AndyAinscowCommented:
Ah, you have spawned a new question.
The map mode of your view is probably with the vertical direction differently orientated as the co-ordinate system.
Check which map mode you use.
Use SetWindowExt or SetViewportExt to 'flip' the y direction OR just do it yourself  cy(window height)-y(mouse co-ordinate)
0
 
PMH4514Author Commented:
>>that gives me an idea..  be back later..
nope, nevermind :)  I had:
      pbmInfo->bmiHeader.biHeight=m_Height*-1;  

relating to the bitmap I was capturing from my camera.. by removing the *-1 only kept my camera image upside down, didn't change the cross-hair backward Y movement.

>>The map mode of your view is probably with the vertical direction differently orientated as the co-ordinate system.
this "map mode" is new to me!

I just ran this:
      CSize pSize = pDC->GetWindowExt();

and I get pSize = {cx=1, cy=1}

wouldn't that be normal? what exactly does the 1 refer to? are we talking about weather the Y axis goes from low to high vs. high to low when moving from "top" to "bottom" of the screen??

-paul
0
 
PMH4514Author Commented:
I tried doing:
      pDC->SetWindowExt(1,-1);


but nothing changed.

I did try doing "it myself" and just pointing to y = 1024-m_pMouseLoc->y   (I just threw 1024 in there quick and dirty, that's the height of my screen, I know that's "wrong")

- this now works, but of course since I just threw in 1024, the line is like 20 or so pixels above the actual mouse locY.  But I "don't like" having to do this.. Is this "normal" for the y axis to be flipped? Why didn't calling SetWindowExt(1,-1) change if it this is the case?

Finally, I know hard-coding 1024 was wrong, it was just to see if it worked, but how do I derive the value to use in it's place?

thanks!
-Paul
0
 
PMH4514Author Commented:
well, my Y axis is definitely inverted.. I just did a MoveTo(1,1) / LineTo(10,10) and I got a line 10 pixels in length coming up to the right from the lower left corner of the screen.
0
 
AndyAinscowCommented:
Have a look at SetMapMode in the help.  That should give you an insight into possibilities when drawing.
0
 
PMH4514Author Commented:
Ok will do..

0
 
SteHCommented:
Got an idea from Ruskialt's comment in your other thread:

Are you displaying this line directly or is there some bitblt/strechblt involved which inverts the y-order?
0
 
PMH4514Author Commented:
SteH -I was just reading Ruskialt's comment on my other thread :) Check out the comment I just added, the problem is in 2 Y locations now.


I am not displaying the line directly. And perhaps here lies the problem, or at least, a problem which I can't point to any further details.

I have a Lumenera digital scientific camera. The  camera comes with an SDK, and it supports a video streaming mode. Part of this stream is support for a callback function, which I've implemented, which gives access to the pixel data prior to it's being drawn to my owner defined window.

I am using the following code within my callback handler, to "push" my overlay (the lines we are talking about)
into the stream before the camera API handles displaying it:

-----------------------

HDC hDC = CreateCompatibleDC(NULL);
ASSERT(hDC);
CDC* pDC = CDC::FromHandle(hDC);

// Create a bitmap to hold the overlayed result
HBITMAP hbmOverlaid = ::CreateDIBSection(hDC, pbmInfo, DIB_PAL_COLORS, (void**)pData, NULL,  NULL);
int iSetCount = ::SetDIBits(hDC, hbmOverlaid, 0, m_Height, pData, pbmInfo, DIB_PAL_COLORS);

HBITMAP hbmOldDest = (HBITMAP)::SelectObject(hDC, hbmOverlaid );

m_pReticle->DrawReticle(pDC);      

// select the new image back into pData, for Lucam API to display in view window.
int iGetCount = ::GetBitmapBits(hbmOverlaid, length, pData);


-----------------------


It is within pReticle->DrawReticle(..) that the code in this EE thread is.

0
 
SteHCommented:
Is there some documentation from the camera manufacterer on how the axis orientations are for his displaying? Is any zooming of the window activ? (This could result in a StrechBlt call inside the driver.)
0
 
SteHCommented:
I guess you have to get used to the fact that your coordinates are using the conventional order x increasing from left to right and y from bottom to top. That's easy to implement unlike the missing pixels in lines from the other thread.
0
 
PMH4514Author Commented:
Yeah, I'm not really concerned about the upside down Y anymore, now that I know that's the case..  The missing pixels is very strange.. even more strange that it went from one line through Y=500 to two lines through Y=250 and Y=750

0
 
PMH4514Author Commented:
oh and no, the dox don't say how the API is pushing the data into the device context.. I'll have to contact tech support.
0
 
SteHCommented:
I am not sure if you have perhaps missed my comment on mapping modes at
http://www.experts-exchange.com/Q_21213545.html#12627970. I could understand a split but not why that comment was more helpful than mine.
0
 
PMH4514Author Commented:
SteH -I know this is an old thread, I was just revisiting it..  I don't think I ever noticed that last comment of yours.. Did I neglect a concern of yours over a split? That thread you pointed to is this thread, please point me to the one to which you were referring so I can make right any wrongs :)

-Paul
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 11
  • 5
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now