cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X

Avoid to create repeated XUI dialogs

pzorrilla
1-Newbie

Avoid to create repeated XUI dialogs

Hello Guys!

So I'm working on the creation of an XUI dialog in Arbortext Editor, what I would like to know is if there's a way to avoid to create the dialog twice. The way how I create the dialog is creating a new option in the menus bar and from there I call the script to create the window. I have another window and I'm using a global variable to store its ID so I can validate if the window is active or don't, however I think I can improve that method.

Any ideas?

In advance I appreciate so much your time!

Paulette

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Paulette--

That's simply a function that retrieves some arbitrary bit of data that has been associated with the window, using window_set_data(). Both functions are defined in $ARBORTEXT/packages/main/_winhook.acl.

All it does is create an associative array of key/value pairs that is tied to the window (by its ID). The function you mentioned is used to look up the data after it's been set.

--Clay

View solution in original post

11 REPLIES 11
hbestler
12-Amethyst
(To:pzorrilla)

Hi Paulette,

we have the same problem. We also do this by saving the window-id in a global variable and destroy the window before we load another xui dialog.

But if we want to dock a window below and would like "refresh" or load this docked xui-window again, this method (with global id) does not work.

Maybe there is a better way to reload xui-dialogs and someone can help us.

Greetings from Germany

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 Clay,

thank you! Especially for your tip with the functions in _xmldlg.acl. This is very helpful!

We will also check your suggestion with the xui-window.

Thanks again.

Hubert, Clay!

Thank you so much for your responses, I've never though on the array to keep a register of the created windows, I've been working with _xmldlg.acl file, but I wasn't sure about how to use some of the methods there for my purposes.

Guys!

I have another question, how can I assign the same function as a callback in a dialog? Let's say I have three buttons in one dialog and I created a function that validates the events and item that calls the function, do I have to assign the callback to the whole window?

Thank you!

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

Clay!

Can I use this functions in my proper implementations? Is that possible? I'm not sure how can I call them. Should I use the source or the require commands?

thank you!

Paulette

Hi Paulette--

You would use this the same way you use other callbacks. Write your _notify() function with a signature to match the window notify callback:

     function _notify(win, dlgitem, event, data, appdata)

Make sure it's loaded at start up so the function is available, and attach it to the dialog window when you create the dialog, using window_add_callback(). See the online help for window_add_callback() for details on that.

Again, looking through the stock Arbortext code base (in $ARBORTEXT/packages/*) will be a good guide in how this is typically used.

--Clay

Clay!

I have one more question XD ...I found a method in some scripts (inside $ARBORTEXT/packages/main/*😞 window_data(), I can not find any information about it, I searched in the Arbortext Command Language Reference but I had not any luck, I tried also in Arbortext Help but nothing

Is there any chance you could help me with that?

In advance I appreciate your time and help.

Paulette

Hi Paulette--

That's simply a function that retrieves some arbitrary bit of data that has been associated with the window, using window_set_data(). Both functions are defined in $ARBORTEXT/packages/main/_winhook.acl.

All it does is create an associative array of key/value pairs that is tied to the window (by its ID). The function you mentioned is used to look up the data after it's been set.

--Clay

Clay!

As always thank you so much! I tried to find the function inside any of the acl files but I hadn't any luck. I appreciate your help.

Paulette

Top Tags