I have a script that does a lengthy operation within a loop on a button pressed event. I would like to provide a cancel button for the user to halt the exection. If I add the button to the rollout clicking it doesnt help because the cancel button’s on pressed event doesnt get registered until the other operation finishes.
Is there a standard way to solve this problem?
You’ve also got to remember that you code is executing in the same thread as the ui (more or less). This makes it next to impossible for maxscript to respond to a ui request (such as a button press) because it has not yet finished doing its current work.
Just like men, it can’t do more then one thing at a time…it takes women to multi task…
Bozar’s suggestion is probably the only way you are going to find to solve this issue.
I’d love to see threading support in max script…but then again, it is just max script
Shane
getProgressCancel()
A low-overhead function that checks whether the user has canceled the operation via the Cancel button in the progress bar. You may want to call this function frequently within deep loops in your code to reduce cancel latency for the user, because you should only call progressUpdate() as needed to show significant progress bar changes to keep overhead low. The getProgressCancel() function, as well as progressUpdate(), displays a confirmation dialog if the use hits the cancel button and returns the cancel status from that confirmation. Unlike progressUpdate(), this function returns true if the user has made a confirmed cancel request and false otherwise.
I know the dotnet framework allows you to spawn a new thread, but I’m not sure if you’re allowed to bring that into maxscript.
You have a number of issues that need to be resovolved before you even attempt this…
If you want to spawn a thread to do the work, that thread won’t be able to interact with the ui (well, it can, but it shouldn’t), unless dotnet supplies some way to sync calls to the ui thread. Which brings you to the next issue…how to you get your result from the dotnet thread back into the ui thread so you can do something with it?!
You also have scope issues…how would maxscript handle the scope of the variables?? It’s bad enough practice in modern languages to modify variables that other threads rely on!?
Thread syncronisation can be a pain in c/c++, java and I’d imagin python as well, it takes very careful consideration, planning and design and they are built with multi threading capabilities.
I approach threading issues in java (which has some of the better native threading support I’ve seen for a while) carefully. When it works, it’s great, when it doesn’t…lets just say, debugging maxscript is easier…
Unfortantly, maxscript just wasn’t built for this…doesn’t mean we can’t try.
I’d certainly be interested in seeing some work on it, that’s for sure…but unfortantly, I don’t have access to donnet at work (max 8).
Right now, the progress bar is the best solution…
(by the way, this is just my initial thoughts on the subject and I could certainly be wrong)
Shane