Apache OpenOffice (AOO) Bugzilla – Issue 17613
Add navigation bar functionality to form toolbar buttons
Last modified: 2010-11-10 16:05:11 UTC
As apart of a general enhancement of form design, I suggest that the functions on the form navigation bar (next, new, previous, and so on) be made available as ready-built buttons that can be added to forms from the form design toolbar. these buttons would almost by definition be larger and more conspicious than their equivalents at present on the navigation bar. They could also be placed much more visibly and logically in the context of a form which has to be used by other people. The resulting forms would be easier for developers to build, and for end-users to understand and operate. Such buttons would make potentially powerful features like filter by form (which we need, to work around the known limitaitons of the database model) much more obvious and easy to use. I know that it's possible to build them by hand, slowly, at the moment using standard pushbuttons and attaching them to macros that dispatch the right slots. But they would be much more useful as pre-assembled building bricks.
grabbing, targeting, accepting. (Note that acceptance doesn't mean that we will implement it in any particular way :) We plan to at least offer such functionality in an auto pilot which would be opened once you create a button. Dedicated slots in the form function toolbar may also be worth consideration, though I fear that this bar will become crowded - at the moment, I think the auto pilot solution is a more natural one. Additionally, it would be possible to have the navigation bar as dedicated form control, which then could be placed everywhere where you can place the other controls, and could be customized (to show or hide functionality) in the property browser. Let's see.
Wow, Frank. That's quick, even for you. I couldn't argue at all with te autopilot proposal: I was thinking maybe a tear-off from the function toolbar, which would also keep it uncluttered, but your idea is probably better.
"According to the OpenOffice.org roadmap (http://tools.openoffice.org/releases) this issue was retargeted to OOo Later."
accepting
adding issue 24409, which describes the requirement for a navigation bar form control
adding issue 24415, which describes the requirement for form navigation functionality for push buttons
change subcomponent to 'none'
With issue 24409 and issue 24415 being fixed, we now have - a dedicated navigation bar form control - the possibility to assign action such as "next record" to an arbitrary push button control I claim that the RFE here is fixed by those :)
Andrew, I'd like to ask you to have a look at the functionality in the latest developer snapshot build (http://download.openoffice.org/680/index.html), and either close (preferred :)) or reopen this issue. Thanks.
Sure. It will take me a couple of days, though. There are a number of outstanding bugs in the m3x series which mean I can't write stuff with them and that's how I earn my living. but it's being downloaded now.
Sorry. I can't test this. the m38 build won't install properly on my system. I get and error saying "directxcanvas.uno.dll" could not be registered; if I ignore this, the program appears to install, but just vanishes after the splash screen has been shown. I don't have a functioning linux system to test it on, either. I'll just have to wait for a build I can get running.
OK. I now have it working, and I reckon it looks fine. One small niggle: I think that the orperties sheet would be more informative if it said "show position", "show record navigation" and so on. Or the controls for the four parts of the bar could be in a box labelled "Show/hide". Just to make it easier to see what's happening. A related, but separate issue is that the form control bar is now getting so cluttered that it might benefit form a redesign. I think I will propose that as a separate RFE.
> One small niggle: I think that the orperties sheet would be more informative if > it said "show position", "show record navigation" and so on Agreed. However, given that this would require a specification, an approval, and a linguistic review, I am a little bit reluctant ... > A related, but separate issue is that the form control bar is now getting so > cluttered that it might benefit form a redesign. This is on the plan (also for some other reasons). I strongly hope we can do it 'til 2.0.
>Agreed. However, given that this would require a specification, an approval, >and a linguistic review, I am a little bit reluctant ... I hadn't thought of that. How many languages do you have to prepare this stuff in? Just English and German?
Yes, just german and english. Lemme suggest the following: You submit an issue for the renaming, with the english wording. I add the german wording, and assign the issue to our chief linguist. Given that the changes are really small, she should be able to approve this in a small time frame, and then I'll check in the changes. How about it?
OK. I'll just wait for the next milestone to appear, in the hope that it has fixed the move-by-sentence bug: it seems to have been built, but not made the mirrors yet. I scrubbed the previous 680 releases off, since I can't use them for real work. Thanks for this suggestion.
retargeting for proper "What's new" queries
seems to have made it into the master build ...
Created attachment 73077