What to intercept for an OS closing of a stack to lock messages

[Bob Sneidar]

By the way, error 13 is in fact insufficient permissions, as I suspected, but it was more difficult to determine that that I thought it would be. The usual lists of OS X errors usually skips the first 25 or so on the positive side. My opinion here is that system calls that return an error, should be reported as an LC error so you can trap for them as such. 

I get why LC is somewhat vague about the specifics of the errors, as they might change at some point. There are shell commands you can execute to grep the current error codes, but that may be more that you want to code for if your need is limited. 

Bob



> Not sure what the effect of locking messages would be in the middle of a closeStack. Stack might not close. I seriously doubt however, that your own scripting is taking 4 seconds to run during closeStack! If they are, then perhaps it's time to review the code to see if there is a more efficient way to go about it. Again, without seeing the actual stack(s) it's hard to offer anything more substantial. 
> 
> Bob
> 
> 
> On Oct 5, 2012, at 1:55 PM, Dr. Hawkins wrote:
> 
>> On Fri, Oct 5, 2012 at 1:51 PM, Bob Sneidar <bobs at twft.com> wrote:
>>> There is the shutDownRequest if you are quitting a compiled app. It gets sent to the current card of the main stack!
>>> Make sure you are trapping for it in the mainStack and not another. Be sure to pass it in order to complete the shutdown!
>>> My understanding is that if you don't the SIGTERM sent to the app will be ignored.
>> 
>> It's not the main stack; this is a substack.  But in Mac, it gets it's
>> own close window from the OS.
>> 
>> I just need this substack to close without executing any handlers.
>> 
>> thanks
>