Avoid to create repeated XUI dialogs

Hi Hubert--

I think you could adapt your method (global variable) to accommodate multiple document/windows pretty easily by making it an array, where the index is the doc ID. For example, when you create an instance of the dialog, you can tie it to a particular document something like this:

     global dlg_exists[];

     ...

     function show_dialog(doc) {

          # decide whether to show dialog or not

          if (defined(dlg_exists[doc])) {

               alert("You already have one of these!");

          }

          else {

               # doesn't exist, load it

               local xuiwin = window_create("xui", 0x10, $xuidoc);

               dlg_exists[doc] = xuiwin;

               window_show(xuiwin, 1);

          }

     }

And make sure your dialog event handler clears out the data for the relevant document when the dialog closes, e.g.

     delete(dlg_exists[doc])

That scheme lets you have a separate instance of a dialog for each open document, but never more than one for the same document.

There are also many useful functions defined in the _xmldlg package in $ARBORTEXT/packages/main/_xmldlg.acl. These functions make it easy to use a dialog name to look up its window ID, or to get the XUI document for a dialog, and so on. So, if your dialog is named "myDialog", you can easily test to see if an instance exists by using _xmldlg::findDialog("myDialog"); if it returns a valid window ID, then an instance already exists (and you can use the ID to do whatever you need to with the existing instance, e.g. bring it to the front, or close it to open a fresh instance).

--Clay

Hi Paulette--

Yes, this is a very common pattern. You attach a function, by convention usually named _notify(), to the window, and that function handles most or all of the dialog's interaction. This idiom is used throughout the standard ACL code used in Arbortext Editor. To see an example of this, look at the _notify() function in $ARBORTEXT/packages/main/_finddlg.acl. You can see how it branches based on the event type and dialog item (the activated control).

If you grep "_notify" in the $ARBORTEXT/packages directory, you will find many instances of this pattern, which should give you a pretty good idea how to apply it to your custom dialog.

--Clay