Kbase 13540: problems with DIALOG BOXES - overlay or using other windows
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
problems with DIALOG BOXES - overlay or using other windows
This knowledgebase is intended to address some commonly-expressed
concerns about the DIALOG BOX widget. Why can't you go to other parts
of your application when a dialog box is displayed? Why can't you
overlay other frames on top of it? Here are some explanations.
Why do DIALOG BOXES hog the focus?
----------------------------------
The dialog box widget used in Progress is the native MSW or Motif
dialog box. One characteristic of the native dialog box widget
is its MODALITY. This means that once it's displayed on the screen,
it must be dismissed in some way before any other window in your
application can take focus again. (One exception is when you create
an additional dialog box that is a child of the first one - the
second one will then take precedence over the first. This means you
will have to dismiss *it* before you can dismiss the first one. This
is one example of a "stacked wait-for" situation, but at least the
modality of the dialog boxes prevents the kind of confusion that can
often result with stacked wait-for's.)
You should use a dialog box when you want to make sure a user
will make a decision on an action before other work continues
in your application. One simple example of this is the "Open
File" dialog that is used in the Procedure Editor. Once invoked, it
must be used to either select a file or to cancel the operation by
means of the "Cancel" button. While the "Open File" dialog is on-
screen, the user is incapable of invoking any other feature of the
Procedure Editor. The modal nature of the dialog box enforces this
rule.
This modality feature is one reason dialog boxes are very helpful in
Progress. When using databases, sensible transaction scoping is
critical to data integrity. With multiple window displays there's a
danger of having many records locked in many windows at the same time,
causing multiple transactions to be open simultaneously. This is why
when updating, creating, and deleting records, Progress strongly
recommends that programmers make use of dialog boxes. Their modality
enforces a "one at a time" transaction strategy.
The main window of an application should ideally be used for display
purposes only, perhaps as a mechanism for navigating through the
records in the database. When an update, create, or delete is
desired, the user should have to choose a button or menu option
which carries out the update, create, or delete using a dialog box.
The dialog box will prevent any other application action until its
operation is completed or cancelled - or, in other words, until the
transaction is completed or cancelled. This ensures that the user
won't mistakenly open other transactions before finishing with the
current one.
Why can't other frames be overlayed on top of a DIALOG BOX?
-----------------------------------------------------------
Another feature of the native DIALOG BOX widgets for MS-Windows and
Motif is that they insist on being "in your face" while they're still
active. They don't allow you to place other frames on top of them,
just as they don't let you move focus anyplace else in your
application. This is just one more aspect of the dialog box's
modality. By making sure you can't place other widgets on top of
it, it guarantees that the user won't lose sight of it and "forget"
why the rest of the application is so resistant to taking focus, etc.
If you try to work with the dialog box widget instead of resisting its
native features you'll find that it can be a good friend indeed.
You'll have no worry about multiple transactions resulting in major
loss of data. Without dialog box modality, it would be much more
possibile for users to think they're backing out tiny transactions
whereas due to many active windows they're undoing many - perhaps
even an entire day's work.
Progress Software Technical Support Note # 13540