Apache OpenOffice (AOO) Bugzilla – Issue 55128
provide easy possibility to open a (secondary) form upon clicking a form button
Last modified: 2017-05-20 10:48:14 UTC
A often requested functionality when developing database-driven applications is the following: Consider a form displaying some table data, plus a button. When the button is pressed, a secondary form should be opened (ideally modal, which currently seems to be impossible with the forms-are-non-modal-text-documents approach), to allow the user to enter data in some dependent table. After this form is closed, some refreshes to the primary form should be made. Currently, this involves a lot of scripting, and is nearly impossible to all but the most experienced script developers. It would be desirable to simply have an action "open a form" as possible value for the "Action" property of a button (which currently contains actions such as "submit form", "reset form", "load document", "move to next record", and the like), to relieve the user from all this cumbersome and error-prone scripting work.
*** Issue 55127 has been marked as a duplicate of this issue. ***
accepting
for the record: spec for the current "Action"s of the push buttons: http://dba.openoffice.org/specifications/forms/navigation_buttons.sxw
I think having an action property on a button would be great. There are a few things that I wuold point out however. First, having the new form modal or non-nodal really needs to be an option. There have been many when I used a new form as a way of driving the old form. For example the new form might just have a single column grid that the user can type down into or scroll into, this would be used to move the record cursor on the old form, the user may elect to leave this form open and simply move it to the side. Secondly it may not be a good idea to get to caught up with the idea of a Button as the interface for this. Double clicking on a row in a grid and then opening up a detail form for the record, or records, represented by that row is a very common function. Another part of this, IMO, is having the formdef as the object that is used to keep the form alive. With this approach, even if the actual variable is hidden under wraps form the developer, there is the opportunity to have only one instance of a form open at any given time. There are lots of places where this definite short coming. For example in EIS style applications it is common to open more then one of the same form, setting different filtering options in each so that the user can compare results side by side as it where. Another use is when one develops a form template, many controls added at edit time, then a few added at run time as needed to make different instances of the form.
Some ideas touching the subject: If actions were implemented like described in the "navigation_buttons.sxw" spec it would be nice to have them not only bound to buttons, like suggested earlier. At least I can imagine a custom menu entry launching forms for fulfilling the needs of a database app. That would build a bridge to other applications like writer and calc, too. Think of action objects in Java bound to menus or buttons and you'll get the idea. Another related topic is "multi window" capability. Frank mentioned modal forms which are one method of getting switchable forms. Others would be using MDI (only inside a base document for db apps) or some form of "tabbed notebook" (as called in GTK+) like for the tables in a calc doc. One could open a bunch of forms and switch around easily by clicking tabs at the edge of the document window (maybe the implementation in calc can be reused here). If the developer wants full control over form switching he should be able to hide the tabs. Another profit gained would be having references to the forms for checking instance count and keeping forms alive. If non modal forms are used it might be handy to have a parameter for storing info about the caller. For example if a user is filling in orders to one form and has to add a new customer inbetween, the orders form could be re-activated automagically after closing the customers form. The first opened or master form then can be identified by checking the caller ref for a NULL value.
*** Issue 60845 has been marked as a duplicate of this issue. ***
Reset assigne to the default "issues@openoffice.apache.org".