Width, Height, Top, Left Properties keep jumping around / won't accept value (1 Viewer)

Cark

Registered User.
Local time
Yesterday, 18:51
Joined
Dec 13, 2016
Messages
153
I have been dealing with this issue for quite a while by just accepting it happening, however I am now wanting to ensure things are lining up perfectly and am wanting to use the Top and Left Properties for objects to align them.

However when I try aligning two items next to each other, they don't seem to want to go together. I have one Label at Top = 0.053cm and I try making the second Label go to Top = 0.053 and Access autocorrects it to 0.055. Any idea on how to rectify this?
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Today, 09:51
Joined
May 7, 2009
Messages
19,169
use Arrange Menu on the ribbon.
select two, three or group of controls then Align them.
 

Cark

Registered User.
Local time
Yesterday, 18:51
Joined
Dec 13, 2016
Messages
153
Thanks arnelgp, this has definitely helped when a control is already at a certain Top value e.g 0.741cm. However, when I have just copied across 4 controls from another Form, they automatically go to Top = 0cm and Left = 0cm. I try to move them to 0.741cm, but for some reason they jump to 0.743cm. I have been unable to get one of them to move to 0.741cm to use the Align technique.

Am I doing something incorrectly?
 

isladogs

MVP / VIP
Local time
Today, 01:51
Joined
Jan 14, 2017
Messages
18,186
In that situation, I set the control to slightly less than I want e.g. 0.74cm and it usually adjusts to the desired value 0.741cm
 

Cark

Registered User.
Local time
Yesterday, 18:51
Joined
Dec 13, 2016
Messages
153
I have been trying that technique Isladogs, however it still jumped up to 0.743. It seems as though Access sets up some sort of grid system (although it is not the snap to grid kind), where it only accepts certain intervals. Weirdly though, the intervals stay the same, but the values it locks to change. Not sure what triggers this.
 

isladogs

MVP / VIP
Local time
Today, 01:51
Joined
Jan 14, 2017
Messages
18,186
It does have a grid system of some kind though it can be overwritten in the way I suggested and by using the alignment controls.
Just tested with these results
0.739 - OK
0.74 - changed to .741 as I suggested
.741 / .742 - changed to .743
.743 - changed to .744

In reality will anyone notice the difference to this level of precision?
 

Mark_

Longboard on the internet
Local time
Yesterday, 18:51
Joined
Sep 12, 2017
Messages
2,111
If I remember correctly, this is also impacted by the resolution your monitor is set to. I remember having this issue when two different computers (older with lower res monitor) wouldn't let the same values be entered.

Are you working on a different computer than the one the database was originally created in? Alternately have you changed screen resolution?
 

isladogs

MVP / VIP
Local time
Today, 01:51
Joined
Jan 14, 2017
Messages
18,186
Mark
The effect described also occurs in a brand new database. Its been an irritation for years that I've learned to just work around.
 

Cronk

Registered User.
Local time
Today, 12:51
Joined
Jul 4, 2013
Messages
2,770
If it really is that critical, in your form load event,
Code:
me.YourLabelName.top = 30
 

CJ_London

Super Moderator
Staff member
Local time
Today, 01:51
Joined
Feb 19, 2013
Messages
16,553
it's because the properties are actually stored as twips -1440 twips = 1 inch

ergo 566.929133858268 twips is 1 cm which rounds to 567

so you enter a .053cm value - that is converted to 30.0472440944882 but is rounded up to 31

31 twips converts back to .055cm

I don't know why it rounds up and I'm pretty sure I've seen typed values go down as well. I suspect it may have something to do with the conversion to twips in that .053 is stored as 31 twips - so the conversion back to cm is 'correct'
 

isladogs

MVP / VIP
Local time
Today, 01:51
Joined
Jan 14, 2017
Messages
18,186
I think the twips to cm / inch conversion is only a partial explanation.

If you look at my test values from post #18, Access will convert 0.741/0.742 (420+ twips) to 0.743 which is slightly above 421 twips but if you enter 0.743 it changes that value to 0.744 (approx. 422 twips)
It seems to (almost) always round up from the entered value
Logically I might expect it to accept 0.743 as 421 twips.

Also 0.739 cm is a smidgen over 419 twips but isn't rounded up

NOTE: I'm assuming a multiplying factor of 567 rather than the more precise version given by CJL as you can't have a part twip!

There are clearly numerous other similar examples.
However as I said earlier, I doubt anyone will notice to that degree of precision
 
Last edited:

CJ_London

Super Moderator
Staff member
Local time
Today, 01:51
Joined
Feb 19, 2013
Messages
16,553
I'm assuming a multiplying factor of 567
the weenie bits matter!

using those values in the immediate window

?0.741*(1440/2.54)
420.094488188976
?0.742*(1440/2.54)
420.661417322835

both round up to 421 twips
convert back to cm
?round(421/1440*2.54,3)
0.743

next example
?0.743*(1440/2.54)
421.228346456693

round up to 422 twips
convert back to cm
?round(422/1440*2.54,3)
0.744

and final example
?0.739*(1440/2.54)
418.96062992126
round up to 419 twips
convert back to cm
?round(419/1440*2.54,3)
0.739

Not sure for the reason for round up - the smallest value you can enter (other than zero) is 0.001

?0.001*(1440/2.54)
0.566929133858268

which would round up anyway to 1 twip.

Perhaps something to do with inches? 0.001 inches would be 1.44 twips Perhaps one of our American cousins can check? Or perhaps inches goes to 4dp?

Anyway, as stated the difference is a maximum of 1 twip - approx 1 hundredth of a milimetre
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 20:51
Joined
Feb 28, 2001
Messages
27,001
For our friends who use cm for length or height units, the problem is that the unit of TWIPS (as so correctly brought up by CJL) doesn't come out even in metric units. You have to remember that there are 1440 twips per inch. But this unit is 12x12x10, so that means that you can divide 1440 evenly by 2, 3, 4, 5, 6, 8, 9, 10, and 12. (7 won't make it and neither will 11). So units of 1/2 inch, 1/3 inch, 1/4 inch, 1/5 inch, 1/8 inch, and even 1/16 inch divide evenly into to the twips unit. But for cm, that 2.54 cm/inch conversion just confuses the works tremendously. Lots of roundoff issues.

I know that if I am attempting something extremely precise when sizing something, if it pick something that doesn't divide evenly into 1440, I get that jumping around, too. I think it occurs because the display driver has to convert the length to twips as an integer and if it doesn't come out even, then Access "adjusts" the number to one that DOES come out as even as possible.
 

Users who are viewing this thread

Top Bottom