I am trying to vertically position a number of webbuttons over a canvas. The canvas has some lines drawn on it that create cells which the button is supposed to be centered in.
It appears that the resolution of vertical positioning is only about 5 pixels which isn’t accurate enough. The webbutons aren’t centered in the webcanvas cells and the webbutons don’t space evenly on top of the canvas.
I verified this by moving the button down 1 pixel every second. This results in the webbuton only moving about once every 5 seconds.
Is this vertical position resolution by design? If so, is there any way around it? If I have to I will redesign everything to be multiples of 5 but this is obviously not ideal.
I’m not seeing this. I can place buttons at 1 pixel increments both in the IDE and through code and it works correctly. There must be something else in your project that’s causing this.
What version of Xojo? Which platform? Which browser?
Try copying (or recreating) the layout to a new project and see if the problem still occurs.
Turning off the locks keeps the control relatively centered when resizing the page. I think the reason for what you’re observing has something to do with rounding when the framework is calculating the position relative to the current page size. If you reduce the size and minimum size of the page to something small, like 100x100, and resize the browser window the same while running it, you will see the position update at every timer cycle.
The bottom line is, if you want complete control over the position, use the default left and top locks. Anything else, and you’ll be fighting the framework’s attempt at relative positioning (try resizing your browser while running your current layout - I’ll bet it will go all wonky).
Understood. And you are right, the horizontal positioning was also lower resolution; I just didn’t check that before.
Seems a bit glitchy to me but I’ll roll with it. Like I said, I was unlocking everything because there was no way to avoid having to position stuff in code.
You’re thinking about this incorrectly. Locking doesn’t mean you can’t move the control. Locking is about dynamic layout response to page (or container) resizing. That’s why the default is top and left locked, as this means the control won’t “automatically” move - it’ll stay wherever you put it, whether in the IDE or through code.
I follow what you are saying, but how does that explain what happens when you unlock everything? It seems to me that if it causes problems unlocking everything then it shouldn’t be allowed. I was unlocking everything because I didn’t need it and I didn’t want to “fight” with locking I didn’t need. I spent time tracking down this problem and I still don’t know why Xojo behaved the way it did. You mentioned that “…the framework is calculating the position…” but I don’t have any idea what that means.
From my perspective, if unlocking all four sides produces unexpected behavior, it shouldn’t be allowed. That’s all.
Granted, there may be a bug in how unlocked controls respond to position changes through code, but the reality is that you shouldn’t be trying to reposition an unlocked control. If you leave an unlocked control alone, then it works exactly as expected (repositions as the browser window is resized). Realize that when you run your project, the resulting browser window is usually always a different size than your defined page size, so any control that’s not locked to the upper left is going to be repositioned accordingly.
So, as I said before, if you want to properly set the position of a control through code, then you must set the locks at the default (left and top).
I wouldn’t bother, as I can’t fathom a situation where you would really need to adjust the position of unlocked controls. Though a case could be made that position (or size) changes to an unlocked control should be disallowed to prevent confusion.