macOS : cross-process modal window

General
#1

Background

In a standard modal dialog scenario, a user interacts with a Document Window, causing a Modal Dialog Window to appear. Three rules are enforced:

  1. Whilst Modal Dialog Window is visible, user interaction with Document Window is disabled.
  2. Whilst Modal Dialog Window is visible, the OS prevents it from ever going behind Document Window in the Z-Order.
  3. After Modal Dialog Window is dismissed, user interaction with Document Window becomes enabled once again.

In Xojo, this scenario is of course easy to set up, using Window.ShowModal.

Problem

I need to display a Modal Dialog Window, exactly as described above, but with a crucial peculiarity:

In my specific case, Document Window and Modal Dialog Window will not be created by the same process.

There are project-specific technical reasons why this must be so, but for the purposes of this question, assume that Modal Dialog Window will be created and handled by the child process of the process that creates and handles Document Window.

Question

Can anyone outline how to achieve this on macOS? Or provide sample code which may help?

Note

Please see a working proof of concept solution for Windows 10. The following mechanisms allow it to work:

  • Win32 function EnableWindow is used by the parent process to disable Document Window and again to reenable it at a later point
  • Win32 function SetWindowLongPtr(self.handle,GWLP_HWNDPARENT,...) is used by the child process to make Modal Dialog Window an “owned” window of Document Window. This works in Windows 10 even where the owned window is created by a different process to that of the owner window.
#2

LoL. I went looking for some clues on this and found…

… which I wager is your post. :wink:

Offhand I can’t think of a way to do this that is easy/reliable/supported. Probably not what you want to hear, but you should consider refactoring your system so that all the user interactions happen in a single process. There are good automation and security reasons for doing this as well.

#3

AppleScript.
Screen Shot 2022-04-20 at 10.22.35 AM

#4

The AppleScript doesn’t need the tell. But the dialog not modal.

#5

It needs the “tell” to know what process to run the dialog in.

#6

I thought the OP wanted an application to display the dialog, which is what the Tell will do. In this case the dialog was displayed as if it was from the Finder, it also prevented any interaction with other Finder window, which is what I thought the OP wanted.

1 Like
#7

You should not use “tell Finder” anymore.
Current macOS versions use “System Events” e.g.

tell application “System Events” to display dialog “foo” buttons {“bla”} default button 1

#8

You are right.

Unfortunately (just like API2 and 22r1), I stopped the update/upgrade before that.

This signed the declamation of AppleScript…