Dyalog Forums

Hi all,

I love programming with threads: think for an hour, enter an & on the keyboard, watch it all crash and burn, think for hour, move the & somewhere, watch it all crash and burn, repeat....

I have a long running process (LRP), launched from a classic GUI, that I want to be able to kill by clicking a cancel button. However, the process should still be the only thing running.... in other words, the only thing the user can do in addition to letting the process continue is to kill it. He can take no other action.

Note that we don't (want to)know the internals of the LRP.... it may or may not loop, we cannot check from time to time if a variable has been updated.

At a minimum, we need one additional thread -- we need to thread the LRP so we have a thread id to kill.

One technique is to then go back to the main 0 thread and deactivate all (or most) of the other top level GUI objects leaving only access to the Cancel button that will kill the process.

Another option is use two additional threads, one for the LRP and another for a new form with a cancel button and a .Wait or ⎕DQ, and then do a ⎕TSYNC on the LRP thread, thus waiting on both the cancel form, and the process, before going back to the main thread.

The first technique has the advantage of being able to place a cancel button on an existing gui object, and the disadvantage of more housekeeping, tracking what the user may or may not do while the LRP is running. The opposite holds for the second technique.

Question: any obvious other solutions I am missing?

Also, if anyone has any easily shared multi-threading recipes or patterns for GUI responsiveness problems of any type, I would love to see them.

Thanks

But have you thought of how the main gui should behave, to be a good Windows citizen? Came to my mind, that if you do not leave the overall gui available for "other, simultaneous use" while running the LRP in a separate thread, maybe you actually should disable all gui elements? Leaving all other buttons and fields active implies that the user is free to use'em?

Disabeling everything else? Hm, small dfn, recursively dig through the hierarchies, find (essential) gui objects and disable, store them with full ns paths for later enabling. Or pre-do that as the gui is up and running? Cache :-)!

Sounds like i'd leave the Cancel and app Exit buttons alive, and:
- press Cancel -> fnKillLRP, enable rest of gui
- press Exit -> enque form close event -> callback fn calls fnKillLRP if LRP=1. Or... bah, maybe just brute force exit.
- close form -> form closing event calls fnKillLRP if LRP=1 or brute force.

(ofc it would be über cool with a progress bar, slotted into the main gui somewhere, nicely updating from the LRP :-).)

Imho, in general, posting messages and inserting nice small delays is the way to manage async stuff. Eg. send event 1337 from xyz to the main .Wait, which then from there kills the (LRP etc) thread.

I have just implemented a solution very similar to your second suggestion. Our case is that we want to be able to cancel a database query (which is performed through a []NA’ed function in a separate thread). The solution was to make a form without borders containing the cancel button only. The form is then placed on top of the form from where the query was requested (in our case as a part of the status bar), and the parent form is simply set inactive until either the cancel button is pressed or the query ends. So the only thing to add to your 2nd suggestion is that you can disable the entire parent form in one go.

Gents,

Been absent from the list for a few weeks. Thanks for the responses. I'm digesting them...

Paul