MouseMove co-ordinates make no sense at all 1

[1DMF]

Hi,

I'm trying to change a parent image control when a button is hovered over in the sub form.

I can achieve this but the screen flickers like mad.

So to try to stop the mouse_even API firing continuously, I'm trying to trap the X/Y co-ordinates so I can see if the mouse has moved to a different control.

However, debuging the Y co-ordinate shows that the number is bizarre and doesn't accurately represent the same location each time.

I'm hovering over the same control, move the mouse a fraction and the Y co-ordinate can vary by over 200 -> that's impossible!

So what gives with the Y co-ordinate passed to the mousemove event handler?

Private Declare Sub mouse_event Lib "user32" (ByVal dwFlags As Long, ByVal dx As Long, ByVal dy As Long, ByVal cButtons As Long, ByVal dwExtraInfo As Long)
Const MOUSEEVENTF_LEFTDOWN = &H2
Const MOUSEEVENTF_LEFTUP = &H4

Private sY As Single

Private Sub LogoHover_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)

    If Y < (sY - 50) Or Y > (sY + 50) Then
        MsgBox ("y = " & Y & ", sY = " & sY)
        sY = Y
        mouse_event MOUSEEVENTF_LEFTDOWN Or MOUSEEVENTF_LEFTUP, 0&, 0&, 0, 0
    End If
    
    If Nz(Me.LogoExt, "") <> "" Then
        Parent.Logo.Picture = cDrive & "\Logos\" & Me.ProviderID & "." & Me.LogoExt
    Else
        Call MouseMove
    End If
    
End Sub

Private Sub MouseMove()
    Parent.Logo.Picture = cDrive & "\Logos\click_logo.bmp"
End Sub

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

You might want to see if my code in thread222-416091 is of any use

 

[1DMF]

Thanks Mike,

So my analysis is right that the built in event for MouseOver provides bogus argument data.

I've decided that the work involved isn't worth the feature, seeing a larger version of the image on hover is nice but not required and as the Mouse event either way can't provide me with the control that created it, the hoops you have to jump though seem OTT.

I'm going to have a popup click event instead, it's just far easier to work with due to the way continuous forms work with current active record.

I'm using Access 2010 is any of this fixed / improved in later versions?

I read that image support is reduced, as the click events are being deprecated, so you have to mess with button controls and images instead, is this the case?

1DMF

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

>?So my analysis is right that the built in event for MouseOver provides bogus argument data

Er, that wasn't what I was confirming. Just providing a decent hover event for you. X and Y cords do exactly what I expect them to on MouseMove. Always have done for many versions of Access. If it didn't work, then you anticipate seeing quirte a number of comments about it on the internet. And Microsoft would fix it, because that would be one heck of a bug.

You are aware that the result is in twips, rather than pixels? Also, a MouseMove event is not sent for every single twip - or pixel - that the mouse moves

SO you might want to look at our code a see if you can figure out why it appears to give spurious results

 

[1DMF]

how many twips are in a millimeter, I don't believe it's 200

Edit : It isn't, it's 56.xxx , which does make a little more sense, but not much more, as I can't understand how a screen displays things in pixels, 1 pixel is .75 of a printers point yet a twip is meant to be 1/20 (one twentieth) of a point. That doesn't compute to me!

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[dhookom]

There are 1440 twips per inch so about 56.xxx per millimeter is correct. Why are you confusing this using points?

Duane
Hook'D on Access
MS Access MVP

 

[strongm]

You're going down the rabbit hole ...

>1 pixel is .75 of a printers point

Says who? That depends on the resolution of the display device.

Windows has two type of measurements: display-dependant and display-independent. Pixels, for example, are display-dependant, whilst points and twips are display-independent. Therefore you cannot state that a pixel is a specific fraction of a point - it depends on the current resolution (your statement is true only for a DPI of 96). Microsoft also confuse the issue by introducing logical inches - this is because the actual DPI of your monitor may not match the DPI used by Windows, so what Windows thinks should be an inch might not display as an inch ... (imagine a line 96 pixels long displayed on a 21" monitor and on a 24" monitor; clearly the line on the 24" will be longer than on the 21" monitor, even though they are both represent a inch. And neither of them will measure an actual inch ... you'd need the line to be 106 pixels on the 21" monitor, and 92 pixels long on the 24". Hence logical inches)

In theory, Windows is supposed to be able to interrogate a monitor and set the dpi appropriately ... but historically graphics drivers (which are responsible for this) tend not to do so.

You might find thread222-455004 and thread222-749258 of some interest, as they go into it in more detail (and I provide some code that will set the correct DPI for a VB6 form, so it displays actual rather than logical, inches and other code that can interrogate a monitor for the correct measurements)

>1 pixel is .75 of a printers point

It's things like this that are the reason that fonts have to be hinted

 

[1DMF]

> You're going down the rabbit hole ...

Help, somebody let me out!!!!

Mike you are a mutant! , I have no idea how you know so much about this stuff, but you never cease to impress and amaze me.

I think I'm happy to stick with my increased sized image object on a continuous form as trying to detect hover over a continuous form control and update a static image source on a parent form is mind bending to say the least!

The original GUI had much smaller rows, before the address was being stored, and I was trying to detect hover over the small icon image and update the top place holder that is used for adding a new provider, now the icon and display size are the same, there is no need to implement this feature as you can see what the image will look like on the web as the control and web sizes are now roughly the same.

Edit: Duane, twips are a measurement of a printer's point according to my research, that's why I mentioned them, and then I read the pixel / point conversion and it all got a bit confusing, as mike has demonstrated.

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

>Mike you are a mutant!

Well, if we manage to sort out this London drink whilst you are on your course in October/November you'll be able to count exactly how many eyes/limbs I actually have ...

 

[1DMF]

>> Well, if we manage to sort out this London drink whilst you are on your course in October/November you'll be able to count exactly how many eyes/limbs I actually have ...

For sure, looking forward to counting them!

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music