Can not prevent Rhino window closing

Hi everyone,

I’m developing Rhino plugin using Rhinocommon. And to prevent data loss I need to keep Rhino running until a data processing is finished.

I tried to override PlugIn.OnShutdown() method. And indeed, I can finish data processing from here. But there is no way for a user to save the results because the Main Rhino window is already closed when OnShutdown() is called.

Does anyone know if there is some way to keep Main Rhino window open in this case? Or are there better places to handle Rhino closing?

Thanks,
Julia

Maybe the RhinoApp.Closing event is called earlier than PlugIn.OnShutDown()?

Hi @menno
Thanks for your response

No, RhinoApp.Closing event is called after PlugIn.OnShutDown(). And unfortunately, here I also don’t see the way to cancel Rhino closing. Seems like this is not possible :confused:

In this case, I would like to receive some confirmation, that it is impossible to prevent Main Rhino window from closing.

Thanks,
Julia

1 Like

I’m confused, where are you performing this calcualtion? Is there any reason you don’t just perform this calculation in a command?

– Dale

It sounds like you are performing processing in a background thread. Would it make more sense to set the document’s modified value to true when the processing begins and block until the processing is complete in the BeginSaveDocument event?

Hi dale,
Thanks for your response

Well, I know that commands are started via command line or via toolbar buttons.
But in my case, I have a custom WPF UI so all calculations should be triggered via this UI. So it seemed rather complicated to bind WPF buttons to start Rhino commands from the code.

Do you think it is better to wrap any calculation in Rhino command even if it is launched from the code?

Thanks,
Julia

Hi @stevebaer
thanks for you help

Good idea. I will definitely try it out.
Could you please share samples with me if there are any.

Thanks,
Julia

So it seemed rather complicated to bind WPF buttons to start Rhino commands from the code.

This is considered to be best practice. The Rhino UI works the same way: each button is tied to a macro that runs a command. There are huge upsides to doing this, one of them being that undo/redo works out of the box. Another is that users get the same “behaviour” from your UI as from Rhino and a third being that if you have a collection of commands, that they are amenable to scripting. Lastly, if you modularize your code properly, it can be re-used in Grasshopper.

1 Like