Flashing dialogue window in script

Help & Support
1

I have written a DOpus script in JScript, using the old standard dialog DOpus.dlg to generate three successive dialogue windows. (An earlier form with only one dialogue window was posted at https://resource.dopus.com/t/web-search-from-opus-using-multiple-search-engines-and-browsers/22040.) It is launched by a global shortcut. The first window launches normally, with normal tab on the taskbar.

But the second and third dialogue windows usually, but not always, flash on and off after launching, with a period of about 1 second, and the tab on the taskbar flashes too. To bring the dialogue windows into focus so that I can work with them, I either click on the window, or press Alt+Shift+Tab.

This happens when there is no other window open, one window open, or many windows open. It happens on desktop and notebook, both fully updated Windows 10 Pro.

Is there some special command that can be used so that the second and third dialog windows are forced to have the focus without mouse or Alt+Shift+Tab? Should each dialogue variable be destroyed before the next is created?

I have used different variable names for the three dialogues, but changing the second to plain
var oDlg = DOpus.dlg
doesn't affect the outcome.
I have written a DOpus script in JScript, using the old standard dialog DOpus.dlg to present three successive dialogue windows. It is launched by a global shortcut. The first window launches normally, with normal tab on the taskbar.

But the second and third dialogue windows usually, but not always, flash on and off after launching, with a period of about 1 second, and the tab on the taskbar flashes too. To bring the dialogue windows into focus so that I can work with them, I either click on the window, or press Alt+Shift+Tab.

This happens when there is no other window open, one window open, or many windows open. It happens on desktop and notebook, both fully updated Windows 10 Pro.

Is there some special command that can be used so that the second and third dialog windows are forced to have the focus without mouse or Alt+Shift+Tab? Should each dialogue variable be destroyed before the next is created?

I used fancy variable names for the second and third dialogues, but changing the second to plain
var oDlg = DOpus.dlg
doesn't affect the outcome.

2

If Opus doesn't have input focus, pushing the global hotkey will allow it to take focus, but only once. So the first dialog will open, and gets focus. After that point, you need to avoid losing focus, or you won't get it back again (without clicking on one of Opus's windows).

If the first dialog closes, focus goes back to the window that had it before, which is probably the one where you pushed the global hotkey, i.e. something that isn't an Opus window. At that point, focus has been lost to the other process. When you open the second dialog, Opus no longer has the right to take focus away from the other process/window and the second dialog will flash instead of gaining focus.

You can avoid the problem by opening the second dialog while the first one is still open. (You should be able to close the first dialog after opening the second one.)

Alternatively, the script could find another Opus window, e.g. a lister, and activate it first before opening any dialogs. Then the focus will go to that Opus window between the first and second dialogs. But that assumes there actually is another window, and would mean that potentially unrelated window jumps to the front when you push your hotkey.

3

Thanks very much, Leo. It's so obvious when you explain it, but I never thought of it. Here is some confirmation:

  • The problem does not arise when the focus was previously on a DOpus lister.
  • It does not arise when the command is launched from a menu button on a lister toolbar.
  • It does arise when launched from a floating toolbar.

But I'm afraid that I don't understand your second-last paragraph:

The only command that I know to open the window is
var nChoiceA = oDlgA.show
But this command closes the window at the end of the command, so I don't know how to open a second window before closing the first.

4

You would need to run a message loop so that you can handle the OK button and open a new dialog before the first one closes.

https://www.gpsoft.com.au/help/opus12/index.html#!Documents/Scripting/Detached_Dialogs.htm

5

Thanks, Leo for the URL. I'm now busily reading the material on Message Loops, which I have previously ignored.

OLD vs NEW DIALOGUE WINDOWS: But first I'm afraid that I have a very basic question. I have always continued using the very old and rather restricted dialogue windows, and I have never ventured to the later message windows, which are configurable, very flexible, and far more attractive. I notice that the Help files now show only the new dialogues in all the pictures of dialogue windows.

QUESTION: Do the Message Loop setups that I need apply to the old dialogue windows as well, or should I be changing over to the later system?

6

I’m not sure if simple script dialogs work with a message loop. I don’t think they do but have never tried it, so I may be wrong.

Thinking about it, can you avoid using multiple dialogs entirety by using one custom dialog that does everything you need in one place? That would be an even better solution.

7

Well, at least I asked a good question! I will experiment with Message Loops in the old dialogues, see what I can do, and report back.

In this particular case, it is not a good solution to have just one dialogue.. I earlier wrote the thing as a single dialogue, but::

  • DOpus provides only five' options', and I needed seven for one group of choices.
  • I successfully added the other group of choices to drop-down arrows on the buttons (and managed to do the necessary modulo arithmetic). But the result was still all very clumsy and tricky to use compared with successive dialogues.

If the Message Loop stuff doesn't work with the old dialogues, I will continue to try to decipher the more recent XML dialogues, and report back.

But again, I am finding that the new dialogues seem rather clumsy:

  • The creation of each dialogue and its script resources seem to be almost impossible without creating them in a button script first, and then copying, pasting, and adapting to a script addin. (I can now do this.)
  • The placing of the XML script resources within the addin function doesn't seem to work. I had to use a separate XML file, which again is clumsy. I find myself in sympathy with @tbone's complaints a few years ago.

Perhaps DOpus can provide a simpler solution to all this. Surely it is a standard problem that people want to have a multi-dialogue script addin called from a floating toolbar or a global shortcut? I have several such scripts myself, all with the same flashing problem.

Did I write all this? Let me assure you @Leo that I have enormous respect for this software, and for what happens in this Forum. I have learnt so much.

8

If you use a custom dialog, you can add as many controls to it as you want.

True, it's best to do things in a button first, then transfer them.

That's something we're going to make easier for script add-ins in the future.

9

Thanks @Leo. Reporting back on a couple of things:

  • The 'close' property of a button is part of the XML code, and is therefore not available to the old pre-XML dialogues. This alone seems to exclude the pre-XML dialogues from message loops.

  • Because many buttons need to change often over time, I routinely first enter my data into a vector — for example, aEngines below is a vector containing a number of internet search engines and other reference websites. Then I can set up my row of buttons using a 'for' loop, like this:
    var sBns = "|";
    for (nN = 0; nN < aEngines.length; nN++) sBns += aEngines [nN] + "|";
    oDlg.buttons = sBns + "&0. Cancel|";
    This sort of looping is elegant, because it responds immediately if I change the data. But it seems impossible to reproduce when the buttons are hidden away inside the XML code. I would have to copy, paste and edit lines of XML

Am I on track here, or am I missing things? I'm glad that you indicate that things are still in transition, because it would not be good for DOpus dialogues to fall between two stools (both desirable): looking good, and jscript-accessibility.

10

I think you can change labels and hide controls dynamically with custom dialogs. You could also use a listview instead, if the aim is to let people select from multiple search engines.