How to abort Igor quitting?

I am a bit confused. I am going to presume that the "other commands" are outside of the Igor Pro application. Can you use the IgorBeforeQuitHook to put up a BIG FLASHING DIALOG DANGER BOX? Warn the user to run the other commands first before pressing the YES QUIT NOW button.

Otherwise, I don't see how your request accomplishes anything other than preventing Igor Pro from ever shutting down. What test would you have to allow the return value to be anything else but 2.

Perhaps you should better clarify the flow process of this new feature in how it impacts your code.

Also, to be somewhat further puzzled and perhaps blunt in reply, I imagine that IgorBeforeQuitHook was designed exactly for the reason that you can include function calls such as closeIt(... dummy inputs ...) with less effort than writing dialog boxes that themselves can be bypassed. You are already willing to program to check that everything is closed, yet you cannot take the time and/or effort to actually program to close things??? 

So again, please clarify what you really need to do.

* Pause for USER to manually close/disconnect stuff external to Igor Pro --> use a  (pause for user validation) DANGER DO THIS FIRST dialog box
* Allow USER to close stuff properly using only Igor Pro --> instead of writing functions to check and then using a return 2 to abort, write functions to shut down when a user shuts down

No, all commands to be executed are Igor ones.

The working flow would be a checking function executed by IgorBeforeQuitHook , returning 0 if everything is ok and 2 otherwise. Why is this way easier than implementing the closing functions inside IgorBeforeQuitHook? Because that would need the implementation of handling every single possible error which might be quite a lot and, as always, users find unexpected ways of messing things up. Moreover, this setup in particular is handled by several users which might made certain hardware changes.

Regarding your suggestions:

1- A DoAlert/PauseForUser are easily bypassed. Moreover, even if there is any error the user will get to the end of IgorBeforeQuitHook and might exit the software anyways.

2- Already suggested by me in the question. It is OBVIOUSLY the optimum solution, but as I said it might face unexpected errors which are not properly handled.

On the other hand, impeding the user to exit Igor if something is not ok forces them to recheck it until it is (of course they can shut down the whole computer, but let's assumed they won't do that). Furthermore, abort igor quitting allows for an easier way of handling errors, so if any unexpected error appears the checking function returns 2 aborting Igor's quitting.

Thank you. I see the issue better. I was not anticipating the shut down operation would have to handle errors from the internal routines as well.

So, the one immediately viable option is to create a written document called ShutDown Procedure AND add a DoAlert/PauseForUser that references the ShutDown Procedure. Yes, the dialog option can be bypassed (the operator can just hit a master kill switch to shut off the computer). At least you can give the proper warning and reference the right way for the next time.

Also, given that you have such fragile code to be run by a multitude of (untested or untrusted) users, have you considered implementing a user logbook and establishing that you have the authority to ban users who do not follow the (startup and) shutdown protocols religiously? To put this in perspective, I have hardware running on WindowsXP that must be shut down in a specific manner, with the danger of blowing out electronics that are no longer replaceable. We have protocols, logbooks, and regulations in place exactly for this reason.

Thank you jjweimer, I appreciate your suggestions. I have thought about the alert, but I wanted to be a little more harsh on careless users.

Well, I would not say that the code is fragile, but dealing with devices that are also managed by users offers an endless list of possible errors (something as dumb as trying to disconnect something that has already been shut down by a careless hurried user).

Regarding the logbook... you read my mind! One of the functions implemented in IgorBeforeQuitHook popup a DoPrompt to force the user to record a log if any device was connected. Avoiding the log record would suffice to ban a user as you propose but again, if they cannot exit Igor is one way to reinforce them to write down the log (and I'd rather have a log file and safe equipment than banned users and a broken setup).

> I have thought about the alert, but I wanted to be a little more harsh on careless users.

I suspect from all of this that, like me, you are concerned first with protecting the instrument and secondly with banning careless users.

The greater threat that I face is that (blatantly) careless users will physically kill the instrument. So, I also require TRAINING and CERTIFICATION for anyone who wants to be permitted to use the system.

Given the similarity of the situation that you face, perhaps, in addition to a log book, you should implement a training process to certify users BEFORE they are allowed to use the system.

> One of the functions implemented in IgorBeforeQuitHook popup a DoPrompt to force the user to record a log if any device was connected. 

You might find use for the LogBook package.

https://www.wavemetrics.com/project/LogBook

I developed it so that I can record snapshots of any or all windows with notes. By example, I use it to log steps in analysis of research data as well as to record answer keys to class assignments on multiple input steps.

Keep in mind that if someone wants to quit Igor to avoid your possibly troublesome hooks, they can just kill Igor from task manager or the equivalent. Also, Igor can crash, which would avoid your shutdown code. Or the code could be in an uncompiled state, and Igor would quit, which would avoid the shutdown code.

Also, it's not clear to me why returning 1 from IgorBeforeQuitHook won't accomplish what you're after. How would your proposed return value of 2 differ from the current behavior when IgorBeforeQuitHook returns 1?

I really hesitate to suggest this, but you could prevent quitting before proper procedures are taken with

It would require that some code be available that then executes

What are the consequences of failing to follow proper quitting process? Bodily harm? Damage to expensive equipment? As aclight points out, Igor could crash, a power failure could simply shut everything down, there are lots of ways things can go wrong. If the consequences are dire, you hardware needs to be designed to be failsafe.

Thanks for the package jjweimer, I wasn't aware of it. We'll certainly make good use of it!

aclight, I thought the same when I read the Igor Manual who states: "If IgorBeforeQuitHook returns 1, then the quit is aborted." However, what this actually means is that the quitting process is aborted not the quit itself (quite puzzling explanation I know). This means that Igor quits without checking if there are any unsaved data, modified procedures, etc, being quite the opposite of what I'm trying to accomplish.

Of course, there are many possibilities of the system crashing and Igor closing unexpectedly. The consequences of not closing the device properly are not that harmful but I just wanted to force users, or at least make it less easy for them, to avoid the proper disconnection process. It's true that they can close Igor from the task manager or even plug off the entire computer. Nevertheless, I think (or maybe hope) that most people might close Igor and click yes to every warning and popup without reading than purposely close Igor by others, let's say more drastic, methods.

johnweek thanks for the suggestion. As you say, some code should enable that option afterward and that might have some pros and cons, so I get why you hesitate about suggesting it. However, that only disables the Exit option in the File Menu while, in my experience, most people leave using the cross at the top right corner which cannot be disabled.

@ilomdez: I see your point. I agree that the current behavior doesn't match the behavior I expect from reading the documentation. I've brought this to the attention of the hooks expert so he can investigate.

The nightly build of Igor 8.05b1 will handle a return value of 2 as you requested:

IgorBeforeQuitHook should normally return 0. In this case, Igor presents the "Do you want to save" dialog, and if the user approves, proceeds with the quit, which includes calling IgorQuitHook.

If IgorBeforeQuitHook returns 1, then the normal save-and-quit process is aborted and Igor quits immediately. The current experiment, notebooks, and procedures are not saved, no dialogs are presented to the user, and IgorQuitHook is not called.

If IgorBeforeQuitHook returns 2, then the normal save-and-quit process is aborted and Igor does not quit. The current experiment, notebooks, and procedures are not saved, no dialogs are presented to the user, and IgorQuitHook is not called. This return value was first supported in Igor 8.05.

Great!!! Thanks Jim.

Wow, didn't expect such an instant update, thank you!!!