[javascript] non-modal dialogs

[Mathew]

I appreciate that this is another long-shot feature request and that given the developer workload it may be a dream. Nonetheless, I think this would be an incredibly valuable feature and want to put it out there for consideration:

Currently app.execDialog() blocks all user input and actions until the dialog is closed. It is possible to make changes to the document and have them show during the dialog, but a user cannot, for example, change the page, draw annotations or select annotations while the dialog is active. There is a non-modal dialog (app.thermometer) but it is a very specific and limited function. If there were a way to have a non-modal app.asyncDialog() it opens a range of possibilities for scripts (some of which could reduce pressure on other aspects of developer time ).

For example:

• Bookmarks: It would be possible to make a dialog listing bookmarks along with other properties of the bookmarks (such as page number ) with actions for those bookmarks (ie goto page, change, etc). This could be open alongside another pane, so the user could continue using the document without closing the dialog.
• Annotations list: A table view of annotations similar to Bluebeam. It's currently possible as a non-modal dialog, but it cannot stay open while the user interacts with the document.
  image.png
• Custom tools (such as curve drawing, or synchronize views) could have a dialog open while the element is drawn so that user could change properties or cancel, etc while the tool is active. My curve tool uses the thermometer, but as you can see from that tool, it's a clunky workaround. The synchronize views tool relies on the user picking the same menu item again to make changes or cancel it.

Thanks for the consideration!

[Daniel - PDF-XChange]

Hello, Mathew

Yeah that might be a tall order, but I have passed it on. I will keep you posted if I hear good news.

Kind regards,

[Mathew]

I woke up thinking about this one: app.execDialog() is already event-based (ie the methods in the dialog object are called based on user interaction with the dialog). I guess in essence this FR is wanting a way to use the same dialog object, and instead of it returning a result string, it returns a promise (ie an async function).

OK, I'll stop obsessing about it now

[Daniel - PDF-XChange]

Hello, Mathew

Just under half of that flew right over my head, but I suppose I will stop worrying about it as well.
In any case, I will leave the request open ended for the dev team to come take a look if they feel like it. For now, I hope you have a nice day!

Kind regards,

[⚜ Kenny Lemens, P.E. ᵂᴵ]

Greetings Mathew,

It is easy enough to create/use a new thread to work in the background. However, that is not your issue; the issue is that you want a user GUI to appear, and the only object we have that can interact with a user interface is the application itself (THUS: however you call a dialog box, it will force the app to focus and wait until you are done)>

The one workaround that I found is limited, but maybe you can use it as a springboard: Call a *.js file independently. I will note that I did make some regedits back in the day to 'enable' scripts for my computer, so you would need to perform some housekeeping to that end if we expect your computer to run a javascript or vbscript file directly from Windows Explorer.

That is this: create a script and save it to the C: Drive of you computer; you can then call the script through PDF Editor:

Code: Select all

app.launchURL('C:\\Program Files\\Tracker Software\\PDF Editor\\JavaScripts\\msgbox.js')

The 'msgbox.js' file, in turn, would have a message prompt:

Code: Select all

WScript.Echo('Hello World!');

. I don't know how to pass parameters into the script, nor how to pass information back into PDF-XChange: BUT this will at least allow you to display a message alert that doesn't steal all the focus from the editor. To that effect, it doesn't stay 'on top' so it can easily be hidden behind other application windows (i.e., it doesn't force you to Focus on it, thus Windows will not focus on it, and will allow it to be sent to the background.)

May this be of Good Help;
⚜ Kenny Lemens, P.E. ᵂᴵ

[Mathew]

Greetings Mathew,

It is easy enough to create/use a new thread to work in the background. However, that is not your issue; the issue is that you want a user GUI to appear, and the only object we have that can interact with a user interface is the application itself (THUS: however you call a dialog box, it will force the app to focus and wait until you are done)

Hi Kenny,
Thanks for your helpful suggestion. However, I'm looking for something more similar to app.thermometer, or an Excel userform with ShowModal: false
https://learn.microsoft.com/en-us/office/vba/Language/Reference/User-Interface-Help/showmodal-property

- Mathew.

ps In applications, it is very common for dialogs to be non-modal (the Properties, Bookmarks, Thumbnails, etc panes are effectively non-modal dialogs, IMO). Really, the only dialog that you want to block until the user interacts with it is where you cannot proceed until there's an answer (eg a "Save" or "Open" dialog). For a while i was playing with trying to implement a non-modal dialog by using timeouts and adding temporary pdf form elements that watch the view and move with it, but -wow- that added a ton to the undo history and is a major mess.