On a long form, that extends beyond height of screen, whenever one clicks the background the form scrolls all the way back to the top. That is, if you are designing/editing on a control at the bottom of the form, and for any reason you click the background rather than another control, the form scrolls all the way up and you need to scroll all the way back down to continue editing. Not efficient. When editing form, should not automatically scroll to top of form when I click background.
A simple test document is required here. Setting to NEEDINFO, once an attachment is added set to UNCONFIRMED. Thanks
Created attachment 104319 [details] test document to demonstrate bug here is a test document to demonstrate this bug. I noted in making it that the bug is *not* present on LO Base 4.1.6.2/Linux. Bug repeatedly encountered in LO Base 4.3.0.4/Windows7. Per bug report: 1. open Query1 for edit 2. right mouse click on line relationship between two tables in query builder, click edit 3 this dialog box is the problem. LO provides text txplanation for default inner_join that is shorter in length than explanation for LEFT JOIN or RIGHT JOIN, especially where as in test document there are long table names. 4. in Windows 7 or LO 4.3.0.4 or both, the control buttons are at bottom rather than to right in LO 4.1.6.2/Linux. As a result, the long explanation that is inserted in dialog box when selecting LEFT JOIN or RIGHT JOIN pushes the dialog box buttons out of view and the user has to find them by manually resizing the dialog box.
Created attachment 104321 [details] *correct* demonstration document (earlier comment posted to wrong bug) Here is a demonstration document. 1. Open Form1 to *edit* 2. This form has two TextBox controls at the bottom of a very long page. If your screen is so big you don't need to scroll to see the text boxes, zoom out to make the scroll bar appear. 3. Scroll to the bottom of the form in edit view. 4. Click on one of the controls (which are colored red) 5. Click on the white background next to the control. 6. Expected result: the form scrolls back up to the top and user needs to manually scroll back down to the bottom to see the controls again. This result does not occur if you click from one control to the other, so there is a workaround, in addition to scrolling around a lot. However, this is inefficient application behavior.
@Doug : this problem has always been present, even before creation of the current project, e.g. it has been in every iteration of OOo Simple workaround : add appropriate paragraph returns to your Writer form in design mode
Set this as rfe.
(In reply to Alex Thurgood from comment #5) > Set this as rfe. Thx for workaround. Disagree that it is not a bug, I have other bouncy forms too where subform is very long grid, switching into grid in data/normal mode will cause main form to move around for no reason. The ability to type into the background of the data access form ... not seeing why that would be useful. Unexpected that invisible, vestigial background carriage returns would have that effect, partly because from an Access background it is not intuitive that background would have attributes of Writer document, because purpose is quite different. I mean, in light of this feature I would think every form should just have a line of carriage returns down the side as a default.... not seeing why it would make sense to require people to add that just to make form work correctly.
(In reply to Doug from comment #6) > > The ability to type into the background of the data access form ... not > seeing why that would be useful. Unexpected that invisible, vestigial > background carriage returns would have that effect, partly because from an > Access background it is not intuitive that background would have attributes > of Writer document, because purpose is quite different. I mean, in light of > this feature I would think every form should just have a line of carriage > returns down the side as a default.... not seeing why it would make sense to > require people to add that just to make form work correctly. The framework for database forms dating back to the origins of OpenOffice.org was always based on Writer (the ability to use spreadsheets was only introduced later). In case you hadn't noticed, form controls can be anchored, not only to the page as a whole, but alternatively to a given paragraph, to a character, or as a character. This, if I am to understand your reference to Access, actually offers more flexibility for the form developer than Access allows. The point being that Writer allows for form creation independently of any underlying or bound datasource, the fact that one can build database forms on top of the Writer model/view/controller paradigm is an added bonus. I would point out that Base is not Access, nor has it ever pretended to be, and in all likelihood never will be Access, so there are things that are just different. If you feel that any given behaviour can be improved upon, then by all means, please contribute code. Unfortunately, I have no such skills, but I have been using Base in its various forms for nearly 20 years now, and have become aware of its shortcomings and failings. My point here is that LibreOffice Base will only be what its volunteers make it be. Obviously, where coding is concerned, that requires a certain skill set, and the Base module in particular has very few volunteer developers (and none paid) to work on it, so naturally, new developments tend to be limited to suumer of code projects, and people with itches to scratch.
Adding self to CC if not already on