topic Re: Bug or Feature?? in Discussions

Bug or Feature??

ErraticAttack — Sat, 02 Sep 2023 00:40:09 GMT

Quick question for those of you who may know -- if you have an <<On Close() method for a window (say for file-cleanup or some such thing), and a user has multiple edited files open -- if they CTRL-Q and get the popup about unsaved work -- if they then click "Save None", then all windows are immediately killed and the <<On Close() script is _NOT_ called for any of the windows. It is extremely common for users to exit JMP this way, thus pretty much always bypassing all <<On Close() scripts.

Has anyone seen this / aware of any work-arounds?

The main problem I'm running into is that I have JMP launch an event-loop Python script and attach the executable to a window, then I communicate to Python via localhost sockets. The window close script will terminate the Python session gracefully and such. When JMP is closed in the manner above, this doesn't happen and JMP then freezes, but the JMP windows are all gone -- so JMP remains in the Task Manager list with its full set of resources (often more than 1GB) and will only be killed by manually ending the task.

Since the RunProgram result must be tied to an active JMP window (for event-loop purposes I suppose), and since the window gets forcibly closed in the manner I describe above, the RunProgram variable gets destroyed before I'm able to properly shut down Python.

It's a mess and one for which I wish had a solution, but as of yet I'm not seeing it.

Re: Bug or Feature??

Craige_Hales — Sat, 02 Sep 2023 14:05:08 GMT

I used this in the FileSnapper addin to deal with similar issues. RunProgram isn't actually tied to a window, but to the window's context, which can be cloned. As long as a clone or the window refers to the context, it won't be destroyed and the RunProgram scripts will still work. The namespace:evalcontext variable isn't ever used, except to keep the context alive. The RunProgram variable/handle (rp maybe) is also kept in the same namespace because it needs the same lifetime.

// addinLoad.jsl - this is the round-about launcher that uses a clone of a transient
// window's evalcontextbox to keep the evalcontext for a callback script alive.
// ideally, this would be, or directly include, FileSnapper.jsl, but that file 
// constructs a RunProgram callback script that is somehow tied to a transient
// evalcontext that won't be available at callback time.
Local( {bb},
	New Window( "File Snapper Startup", bb = Button Box( "start", Include( "$ADDIN_HOME(com.jmp.hales.FileSnapper)\Additional.jsl" ) ) );
	bb << click; // run the script in this window's context
	// capture the evalcontext, by cloning the box that references it into our namespace
	Namespace( "FileSnapper" ):evalcontext = ((bb << parent) << parent) << clonebox;
	bb << closewindow;
	if(Namespace( "FileSnapper" ):evalcontext<<classname!="EvalContextBox",throw("FileSnapper addinLoad needs EvalContextBox, got "||(((bb << parent) << parent)<<classname)));
);

None of that is documented or promised to work in the future, but it will probably throw a helpful message if something changes.

@jschroedl - ^Q and OnClose scripts

Re: Bug or Feature??

ErraticAttack — Sat, 02 Sep 2023 21:31:55 GMT

Thank you for this! I'll be taking a look at it now and see if it works, but you never fail to give these wonderful gems, so I'm sure it will work for me! This will be awesome for bypassing the window issue!

Re: Bug or Feature??

Craige_Hales — Fri, 08 Sep 2023 15:03:52 GMT

@KennethAdams You're welcome! ( ), or the technique to grab the context? Either feedback is good for JMP dev team.

@jules - Filesnapper might help recover JSL I'm working on, and the context grabber is useful when writing add-ins that launch during startup (and maybe elsewhere.) Both ideas could be better if more integrated into JMP.

Re: Bug or Feature??

jschroedl — Mon, 11 Sep 2023 18:54:42 GMT

Thanks for the heads-up here @Craige_Hales

I have filed an issue to investigate the ^Q + OnClose behavior to see if we can improve things in the future.

Re: Bug or Feature??

ErraticAttack — Tue, 12 Sep 2023 02:20:00 GMT

Note that I've only seen the issue when the ^Q causes the below popup (multiple unsaved files) and the user clicks "Save None"

Re: Bug or Feature??

ErraticAttack — Tue, 12 Sep 2023 14:10:25 GMT

I just finished implementing a persistent Python connection using your trick to get rid of the window -- I can now put the Python session termination script within the AddinUnload.jsl file and it works (JMP doesn't freeze with no windows open, leaving a hidden session that can only be killed via TaskManager)

Thanks so much for your help! With the new persistent Python connection I can offload all of my data-queries to Python and run them in parallel, then JMP will pick up the files when ready for the user to consume, it's great!

Re: Bug or Feature??

ErraticAttack — Wed, 20 Dec 2023 21:06:39 GMT

@jschroedl has there been an update with this? I'm also noticing the same issue when a user selects multiple windows from the Window List and closes them all at once (usually by pressing Delete after selecting them) and if there is a popup about multiple unsaved files, the Save None will close without triggering the OnClose -- exactly the same as above except they're not quitting JMP.

This can leave many resources dangling as the cleanup scripts never run.