AutoScaled Mouse X and Y not integers

[agraham]

The Mouse X and Y values returned by the Form Mouse events can have non-integer values in an AutoScaled application running on a VGA device. It probably doesn't matter most of the time but occasionally it might cause a problem. I think they would be better to be returned as

delMouseDown(Math.Floor(e.X/b4p.fixX).ToString(b4p.cul) ....

 

[Erel]

The advantage of returning non-integer values is that the accuracy is kept 100%.
For example: Button1.Left = Button1.Left will not change the position of the button as expected. This will not always be correct if the number was rounded.
I agree that it is a little bit strange to see non-integer values but as I see it the accuracy is more important here.

 

[agraham]

The advantage of returning non-integer values is that the accuracy is kept 100%.

I don't really agree with that statement. The resolution that the program sees is 320 x 240 so controls are always placed to that resolution and in fact all operatoins are also to that resolution so it seems "correct" to me to return Mouse positions to that same resolution.

 

[agraham]

I had to go and cook the evening meal before I could finish my previous comment. I was commenting about the mouse X and Y and this quote below is not relevant to that. However I can't overlook the opportunity to respond

Button1.Left = Button1.Left will not change the position of the button as expected

In an AutoScaled application the valid range of values for Left are 0 to 239. This will be translated on a VGA device to 0 to 478 in steps of two and retranslated to 0 to 239 when read back so in an AutoScaled application there is no possibility of a fractional value arising in this case.

However if a fractional MouseX value was assigned to a Left property the value is cast to an integer on assignment to the proerty so when read back the Left value would not be the same as the MouseX value that was assigned! If a comparison was then done, for some reason, with the saved MouseX value the comparison would fail and the application would behave differently when run on a QVGA device to when run on a VGA device so I am still of the opinion that the Mouse coordinates should be "Floored" before return.

 

[agraham]

However if a fractional MouseX value was assigned to a Left property the value is cast to an integer...

:signOops: I shouldn't have used Left as an example because it is manipulated by AutoScale. I really had in mind a normal integer property such as Value for a Scrollbar.:sign0013:

 

[Erel]

I will reconsider it in the next version. However as it is currently implemented it is not a simple change as the multiplying (or dividing) code is scattered in many places.

 

[agraham]

the multiplying (or dividing) code is scattered in many places.

Are not changes only needed to the Form and Panel MouseDown, MouseMove and MouseUp code? Other Control properties/values originate in the Designer, or are calculated at runtime, using 320 x240 resolution and so "round trip" OK through AutoScale as integers. Only mouse coordinates originate within the higher resolution space and so only those values coordinates might end up as fractions when AutoScaled down.

 

[Erel]

This is a very good point. And it makes it much simpler.
Will be fixed in the next version.