Issue 55128 - provide easy possibility to open a (secondary) form upon clicking a form button
Summary: provide easy possibility to open a (secondary) form upon clicking a form button
Status: ACCEPTED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 680m130
Hardware: All All
: P3 Trivial with 11 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 55127 (view as issue list)
Depends on:
Blocks:
 
Reported: 2005-09-27 12:08 UTC by Frank Schönheit
Modified: 2017-05-20 10:48 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2005-09-27 12:08:34 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.
Comment 1 Frank Schönheit 2005-09-27 12:15:24 UTC
*** Issue 55127 has been marked as a duplicate of this issue. ***
Comment 2 Frank Schönheit 2005-09-27 12:16:31 UTC
accepting
Comment 3 Frank Schönheit 2005-09-27 12:17:29 UTC
for the record:
spec for the current "Action"s of the push buttons:
http://dba.openoffice.org/specifications/forms/navigation_buttons.sxw
Comment 4 drewjensen.inbox 2005-09-28 10:01:03 UTC
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.

Comment 5 ms2 2005-10-09 09:10:24 UTC
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.
Comment 6 drewjensen.inbox 2008-11-26 04:05:28 UTC
*** Issue 60845 has been marked as a duplicate of this issue. ***
Comment 7 Marcus 2017-05-20 10:48:14 UTC
Reset assigne to the default "issues@openoffice.apache.org".