Is there a way that a script running in one instance of MoI can determine what files are open in all other running instances? Like getting moi.geometryDatabase.currentFileName from each of the other instances?

How about switching windows using a script? Can I get a script running in one instance to switch to the window of another instance?

The situation is that the way I have things set up now it's possible to open a given file in multiple instances of MoI, but I want it to act like the native behavior where if a file is already open in an instance of MoI then instead of launching a second duplicate instance with that same file open, instead I want the window where that file is open to get switched to.

For example, on macOS there's a Window button in the top toolbar that lists all the open windows with a checkmark next to the one that is in front. I want a startup script to get the list of files shown under Window and to move the checkmark to a different file if some conditions are met.

- Peer

Hi Peer,

re:
> Is there a way that a script running in one instance of MoI can determine what
> files are open in all other running instances? Like getting
> moi.geometryDatabase.currentFileName from each of the other instances?

Sorry no there is not any built in facility set up for scripts to do that.

The file name is set on the window title though, so it is probably possible that a helper app written in Swift or Obj-C could enumerate windows looking for titles that end in "- MoI" and harvesting the name preceding that.

Then you could call the app from script in MoI using moi.filesystem.shellExecute( Path, Params, WaitForFinished );

If WaitForFinished = true, there is an object returned that contains properties for .exitCode (numeric process exit code value) and .output (text written to std out for the executed process).


> How about switching windows using a script? Can I get a script running in one
> instance to switch to the window of another instance?

There isn't any way for a script to directly trigger that but if you can get a keystroke generated somehow, Cmd+~ and Cmd+Shift+~ will switch to prev/next windows.

If you can get the pid of the one you want to switch to then the objective-c code for bringing it to the front is like this:

    NSRunningApplication* pApp = [NSRunningApplication runningApplicationWithProcessIdentifier:pid];
    if ( pApp )
        [pApp activateWithOptions:(NSApplicationActivateAllWindows | NSApplicationActivateIgnoringOtherApps)];

- Michael

Hi Michael,

Thank you for thinking about this problem, for the shortcut keys, and for the code snippet.

Seems like it might get fairly involved especially to do it on both Mac and Windows.

How about a way to prevent MoI from starting if the startup script detects a condition? It's not the prettiest solution, but would probably be good enough for my use.

I tried doing this by doing moi.exit() in a startup script, but that causes the new instance of MoI to freeze permanently. Seems like doing moi.exit() in a startup script before the graphics get displayed causes a problem, since it works fine if I do moi.exit() manually right after the graphics load.

Are there any alternatives for causing MoI to exit or a trick to get moi.exit() to work in a startup script?

- Peer

Hi Peer, there is a different type of startup script used for batch processing, where you pass in the script path as a command line parameter to the MoI executable.

http://kyticka.webzdarma.cz/3d/moi/#Batch

Try using that type instead, does moi.exit( true /* suppress save changes */ ); work ok?

- Michael

Hi Peer, also over here I'm not able to reproduce the freeze when calling moi.exit( true ); from a startup script from the "startup" directory.

Does it happen for you if the script just consists only of:

moi.exit( true );

- Michael

Hi Michael,

Re:
> there is a different type of startup script used for batch processing

Good to know, but I don't see how I could use that in this case. I need the startup script to run when I just click on a file in macOS Finder that I've set to open with MoI. I guess that the instance of MoI launched by the OS could run a script from the startup folder that uses shellExecute to run that kind of script, but that seems like it would cause many instances of MoI to start since each would see the script in the startup folder and I'd still have the problem of getting the first one to exit.

Re:
> Does it happen for you if the script just consists only of: moi.exit( true );

Yes if there's another script present in the startup folder that replaces some innerHTML with something involving a command button that includes onclick like this:

var CommandBarFlex = moi.ui.findElement('CommandBarFlex');
CommandBarFlex.innerHTML = '<moi:CommandButton onclick=""></moi:CommandButton>';

but moi.exit() in the first script works fine if the second script only inserts stuff involving command and not onclick like this:

var CommandBarFlex = moi.ui.findElement('CommandBarFlex');
CommandBarFlex.innerHTML = '<moi:CommandButton command=""></moi:CommandButton>';

One puzzling thing is that the freeze occurs regardless of the filenames involved. I thought that startup scripts get executed in alphabetical order, but if the exit script has a name starting with a letter in the middle of the alphabet (like startupScript.js) then it doesn't matter whether the name of the onclick script is a.js or z.js a freeze still occurs. I expected that MoI would exit as soon as startupScript.js runs and z.js would never be reached.

- Peer

Hi Peer,

re:
> Yes if there's another script present in the startup folder that replaces some innerHTML
> with something involving a command button that includes onclick like this:

Thanks, I can reproduce that now, it is a shutdown bug if a control is inserted dynamically but then MoI exits before the control has finished initializing.

I've got a fix prepared which I'll send to you.


> I expected that MoI would exit as soon as startupScript.js runs and z.js would never be reached.

When you call moi.exit() , the moi process is not immediately terminated, a close message is posted to the main window so it will follow the same procedure as the regular window close button being pushed.

So moi.exit() initiates the closing procedure but the app won't actually terminate until after the startup scripts have run and the main event loop processes the posted close event.

I'll set it up so that it will stop executing any more scripts once one has called moi.exit(), and maybe the alphabetic ordering is not working properly I'll check. EDIT: sorting seems to be working ok.

- Michael