Javascript still running when closing iMatch - what happens?

[Carlo Didier]

Stupid question: As everything is asynchronous, if a script sent a request which isn't finished yet and I close iMatch. What happens?

[Mario]

Answered that last week in a post to @ubacher already, can't find it right now.

In short: Shutting down IMatch will close all Chromium browser instances and this stops all running scripts and pending web service calls. It will also of course shut-down the integrated web server in IMatch.

[Carlo Didier]

Is there no way then to tell iMatch to wait until all background processing is finished? Or at least give a warning prompt that not everything is finished, allowing to cancel closing iMatch?

[Mario]

Not really. There is no way for an app to prevent the user from closing the App Panel or the modal and even shutting-down IMatch.

If you do something potentially dangerous in your app, use a modal app. This way your user knows that some app is doing stuff and he cannot close IMatch because the modal blocks the user interface. Note that you cannot prevent he user from closing the modal. This was a design decision because I wanted to prevent buggy apps which break and then don't call modalClose() and thus block IMatch forever.

An app is notified via the standard JavaScipt/Browser plumbing about being closed, but cannot prevent the modal window or App Panel closing.
If you put some code in like this:

$(window).on("unload", function() {
    console.log('Modal window is now closing.');
});


to do something (quick) when the browser instance is closing.
Note that Chromium and other browsers ignore things like alerts or similar when calling from unload. This was abused by web sites which wanted to prevent the user from leaving.

[Carlo Didier]

I don't do anything dangerous in my event scripts, but they assign categories to newly detected images and create stacks based on specific criteria.

The danger is in the fact that these operations could be cancelled before finishing and then those assignments wouldn't be done correctly or completely and there would be no way of knowing that and continuing where it left of when iMatch is restarted (there wouldn't be another "new file added" event for example, as the file(s) would then already be in the databse).

[Mario]

For assigning categories to new or updated images, maybe use the corresponding options provided under Edit > Preferences > Indexing. For automatically stacking files, maybe use the corresponding AutoStack commands.

[Carlo Didier]

As already explained in other threads, this does not work for my workflow and naming convention. And I'm not going through the nightmare of changing those ... (because it would imply, among other things, to rename 90000+ files; not a problem per se, but any existing references to current file names would be anihilated):

- assigning format categories according to MY criteria on aspect ratios - not possible through build-in indexing or existing categories
- automatically stacking composite images (panos, HDRs, ...) based on file names with propagation of certain categories and assignment to specific categories (like "part of pano" for example) - not possible through any build-in mechanism
- automatically add to event categories based on date ranges (actually file name ranges, as the dates are in the file names) - not possible otherwise, except through extremely slow data-driven regex categories

Being able to do these things with event scripts was the biggest advantage of iMatch for me

[Mario]

You still can do that. With apps that react on events. I don't see the problem.
When you shut down IMatch 5 while a script is running, the script is also aborted. Evens may have or may have not fired during shut-down.

[Jingo]

Could you use a log file to write out the events and include an "endpoint" marker that signifies script completion?  This would allow a user to know that the app finished its operations or not before being aborted?

[Mario]

See https://www.photools.com/release-notes/
The next version enables you configure modal apps in a way that a user is being asked before closing them.
And if your app knows that it is finished, it can just close the modal itself.

Apps running in app panels are always "running" and will be closed when IMatch shuts-down. For critical stuff, always use a modal app. The user cannot close IMatch while it is running, at least not without closing it.

[Carlo Didier]

You still can do that. With apps that react on events. I don't see the problem.

True, but with the known caveats, like that the script is not triggered by the events, but the events are monitored by the script which has to be started manually ...

I'll probably have to wrap iMatch into an outer script to do what I want. That script would start iMatch and do the event monitoring through the integrated IMWS.

And to be sure that file treatment is completed for all events, I could use iMatchs automatic assignment to a special category for new images and work on the files in that category.
Maybe then I wouldn't have to monitor events, just that category and treat files that are assigned to it. Complete processing would be signaled by removing the processed files from the category.
In this case, if iMatch is closed before all new/changed files are processed, processing could resume on next start as those files would still have the category assigned.

[Mario]

True, but with the known caveats, like that the script is not triggered by the events, but the events are monitored by the script which has to be started manually ...

Yes. An app can monitor IMatch events and IMWS events. But it has to be started first.
No difference there to the App / Database script in the old IMatch.

If you write scripts which cause problems when interrupted, you need to make precautions.

Windows can shut-down, causing IMatch to shut-down as well. Al scripts stop.
The user can log off. All apps are closed. IMatch must stop all scripts.
A power failure may happen.
Windows may crash.
The user may stop your script.
IMatch sends events to your script before IMatch shuts down, but these events may never reach your script for various reasons...

All this could also happen before, for BASIC scripts of course.

Database and App scripts were always causing problems because they generated so much background load.
Database and event scripts could be very dangerous and cause problems not immediately recognizable for the user.
IMWS can fire thousands of events per minute...

All there were reasons for me to stick to "real" apps and modal apps for a start.
Future IMatch versions may bring enhancements, maybe even a way to automatically run an app when IMatch starts (and keep it running as long as IMatch runs). Many users make demands in many areas. And I of course have my own agenda and to-do list.

[Carlo Didier]

Many users make demands in many areas. And I of course have my own agenda and to-do list.

... which you master astonishingly well! Sometimes I wonder whether you're not living on Earth, but some other planet where the days have 48 hours or more ...

[Mario]

Working 24h at day, and another 24h at night gets a lot more done