This is a bug that probably is connected to: https://bugs.documentfoundation.org/show_bug.cgi?id=113436 https://bugs.documentfoundation.org/show_bug.cgi?id=50206 When in design mode, in a BASE form, you can not move-drag any object outside the visible area of the window (which is a writer window). Forms saved when first opened, either by code or by selecting them in Forms tab of the odb window, are presented with some objects moved from their saved position. The "miracle" is that all subsequent "opens" of these forms, shows objects in their original saved position. This behavior has two major disadvantages. 1. If you open the form in design mode and accidentally save the form then the form is saved with these new (unwanted and clearly not produced by the user) scrambled positions of the objects, making very difficult to recreate the original positions. 2. Final user sees two forms. One when the form is opened for first time and one every time the form is reopened. This behavior is more complicated by the fact that you can set the x and y positions to anything you want using the properties window. Then the window moves to the position of the object. But since there is no horizontal scrollbar if you want to move to another object not visible on visible area the only way is to use either the From Navigator or zoom outside. My opinion is that this «strict to visible» behavior is guilty for the "scrambled" version the first time the form is opened (either in design or in view mode). After that, mayby by "some cached" values, the software is probably aware that there is enough space to set the objects in their saved positions and so any subsequent open of the form does not scramble the objects. Any way, a saved BASE form with saved Top and Left positions for the objects anchored to the page, should never, ever, change their positions. Even if they seem to be outside any «visible concept». Objects in BASE forms are not plain text, thus requiring reposition at the end of some imaginary calculated page width or margin. And the BASE forms should first check the positions. And in extreme cases first re-size the "page" to have these objects in correct (since already saved) positions. Probably, for the moment, this is done in the invert order. First the positions are recalculated and then the page width and margin are adjusted.
(In reply to Ηλίας Ηλιάδης from comment #0) > This behavior is more complicated by the fact that you can set the x and y > positions to anything you want using the properties window. Then the window > moves to the position of the object. But since there is no horizontal > scrollbar if you want to move to another object not visible on visible area > the only way is to use either the From Navigator or zoom outside. This is not true for me. Instead, the object hits the edge of the visible area and when I go back to the position and size, the values have been limited forcefully. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 0929a98acca8ec4d86caa97d3090a39f89f35f90 CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on June 20th 2018
Created attachment 143022 [details] button1 in form upper left This shows the first button in upper left corner.
Created attachment 143023 [details] second button down right In both cases form is saved and reopened for edit. In both cases form design is selected (has the focus), not the properties or form navigator.
The restriction of object position to the canvas is correct, don't see need for input from UX.
Then, let's close. Ηλίας can update to a newer version to see the same behaviour I got in my comment 1.
The version 5.1 is the earliest version I use. The same behavior still exists in Windows 10 using 6.0.3.2(x64).