System.MouseX and System.MouseY values - Normal vs. Contextual Clicks

I’ve got a listbox where I am using the following code ( basically from the LR) to determine the row of the listbox based on the mouse position:

Function GetListboxRow(l as Listbox) As Integer
  Dim xValue As Integer
  xValue = System.MouseX - l.Left - Self.Left // Calculate current mouse position relative to top left of ListBox
  
  Dim yValue As Integer
  yValue = System.MouseY - l.Top - Self.Top // Calculate current mouse position relative to top of ListBox.
  
// Add values for debugging purposes
  Dim smx, smy, lx, ly, sx, sy as integer
  
  smx = System.MouseX
  smy = System.MouseY
  lx  = l.left
  ly = l.top
  sx = self.left
  sy = self.top
  
  Dim row As Integer
  row = l.RowFromXY(xValue, yValue)
  
  Return row
End Function

What’s odd is that when I run this method after a normal mouse click, the row is calculated correctly. However, when running it when I do a contextual click, the System.MouseX and System.MouseY values are completely different.

So for example, if you do a contextual click in a cell, the cell click event first fires. In that event, I get the following values:

System.MouseX = 210
System.MouseY = 131

This gives me an xValue of 190 and a yValue of 66 in the function. And then when using listbox.RowFromXY(xValue,yValue), I get the right row value.

Now, once the cell click event fires, the ConstructContextualMenu event fires. In this event, I get the following values:

System.MouseX = 674
System.MouseY = 268

Completely different! Now I get an xValue of 654 and a yValue of 203. When using these values to calculate the row, I basically get a -1 as a row at those coordinates does not exist.

I know I can easily get the row value in the ConstructContextualMenu event as the local X and Y coordinates of the cursor are passed into the event. So this is more experimental than practical from a use perspective. But should it make a difference?

Why is the System.MouseX and System.MouseY values so different in the ConstructContextualMenu event? I would think they should be the same as in the CellClick event but as you can see - they are nowhere close…

This is in OS X by the way…

Ideas?

Jon

why not just “remember” the X,Y coordinates in the CLICK event and carry them forward,
and ListIndex “should” be the last clicked row

That’s not my point. The ConstructContextualMenu event includes x and y mouse coordinates already. So I can get the row from that.

The point is why does the contextual click report a different System value for the cursor coordinates?

Which platform ?

I wrote a demo that logged the values [OSX]

Notice the first coodinates are X,Y as passed to the MouseDown and ContextMenuClick (CCM)
the second is System.MouseX/Y

the difference is the Left/Top of the listbox itself.

MouseX + Listbox.Left + Window.Left = System.MouseX

System.Mouse is relative to the SCREEN
MouseX is relative to the Control

Mitch - It’s OS X as stated in the original post.

Dave,

You are still not understanding it. I know what you are saying. I’m never calling System.Mouse. I’m only calling System.MouseX and System.MouseY. These are relative to the upper left corner of the screen. They are absolute coordinates.

So, let me try to explain this again as I am obviously not making myself clear:

1.) We have a listbox - OK?
2.) Platform is OS X - OK? I don’t know if this happens on Windows. I haven’t tried it.
3.) If I right click in a cell this is what happens:

  3a.) Cell Click event fires
          - If I call [b]SYSTEM.MOUSEX[/b] and [b]SYSTEM.MOUSEY[/b] in this event I get a set of values for the X,Y coordinates relative to the upper left corner of the screen.

  3b.) ConstructContextualMenu Event Fires
          - If I call [b]SYSTEM.MOUSEX[/b] and [b]SYSTEM.MOUSEY[/b] in this event, I get a DIFFERENT set of values for the X,Y coordinates relative to the upper left corner of the screen.

Is this clear now?

So the question is:

Why do the same system calls return different values from one event to the next?

This really is all I want to know.

[quote=280011:@Jon Ogden]Mitch - It’s OS X as stated in the original post.[/quote] Would have been easier to see in the OS X channel. Sorry, I oversaw the BTW…

Nevermind. My last program Char Menu uses extensively System.MouseX and System.MouseY. I never saw anything strange.

I just created a small test program which displays System.MouseX and System.MouseY in labels, in the MouseDown and MouseUp events of a ListBox. Identical.

Same thing in ConstructContextualMenu.

Something else must be happening in your code.

Did that too. Same values for System.MouseX / …Y for all events (MouseDown, MouseUp, CellClick, etc. both for left and right click).

[quote=280013:@Michel Bujardet]Would have been easier to see in the OS X channel. Sorry, I oversaw the BTW…
[/quote]

The OS X channel is devoted for things solely for OS X. Just because I’m using OS X doesn’t mean that what I am posting about would not happen in Windows as well.

So now when I’m doing this, I’m getting the same value each time just like you guys did. Not sure what I was doing wrong before. Very strange…I swear the values were completely different and all I did was call System.MouseX and System.MouseY. But now I can’t even duplicate my own problem… :confused:

Oh well…

Just saw this thread. I’ve been having something like your problem since a while. I’m using System.MouseX for getting the horizontal offset for a drag image in listbox which lives in a complex window. The code is rather simple:

OffsetX = System.MouseX - (finalDragPicture.Width/2)

I swear: every time I use this the drag picture shows up at a different place. It works, then it’s to the left, then it’s more to the left, then it works again. That crazy or what?

Does a reboot fix it for a time? I’ve seen the OS mess up window coordinates after playing youtube videos fullscreen. What happens is if I move a window then try to resize it’ll jump back to the window bounds before the move. Maybe these sticky coordinates are manifesting in System.MouseXY somehow. A reboot always fixed my problem, until playing youtube fullscreen might trigger it again.

Nope, this issue has survived a couple of restarts. No cat videos on Youtube in full screen.