Dispose or kill a RhinoCommon.command

Hi All,

We have Rhinocommon c# plugin which opens up a Eto form .
The Eto form is instantiated and opened from the RunCommand method using the .show method.

Is there a way to dispose the Rhino.Commands.Command object once we click the close button of the form.

So that each time if we invoke the plugin a new instance will get created. This will help us in initialize lot of static variables in our plugin.

Please share if there is pointers to this.

thanks in advance.

Hello, if you call .ShowModal instead of Show, does this solve the issue for you?

Thanks Tom for the reply.

What I am looking for is dispose or kill the plugin Command object, is there a way we can do that.
here in my case If I am closing the form means, don’t want the command instance to be in the memory.
So that if I launch the plugin again, new command instance will be created.


Well, the ShowModal method will open your window as a dialog on the same thread, causing to stop the command from running until the window closes. Depending on a return code you can tell if the command succeeded or failed. I don’t know if you should “dispose” a command as plugin developer, or even if you can do this from being within a command. Very likely you shouldn’t.

Depending on what you do, you can start the action in another thread and in case you want to abort, you provide a Cancelation token to end the thread/task from running. Or you simply use a (volatile) boolean flag which branches out of a loop in case of abortion. Can you be a bit more precise about your usecase? Can you provide a simple “user story”?

Another question. Why does a Rhino command affect the state of your plugin? You should be totally flexibile in initiating fields and properties? How to you call your plugin inside a command?

This is not how commands work. Why do you need to do this? What problem are you trying to solve?

– Dale

HI Dale,

We have plugin with ETO forms.
I am just wondering what needs to be done if the plugin main form is closed.
Reason is we have some static variable declared in the plugin Command class and values for this variables are assigned inside the RunCommand.
If the user closes the plugin window and once he launch again from the Command by typing the plugin name, it has this static values retained.
Hence thought of disposing the command object every time users close the plugin.



We are opening a form from the RunCommand , inside that we are assigning a Command level static variable with a value based on external api call. Once the user closes the plugin we just want that variable to be cleaned and reinitialized. whats happening now is the variable is retaining that value.
Explained the same to Dale as well
if there is any document for Pugin lifecycle it may help me.

Why? Have you considered creating a C# Singleton class instead, storing your “globals” in there? From there you have full control at any time.

If a reference does prevent a object from being deconstructed, you can use a WeakReference<T>. This allows the GC to free certain types of objects, although still being referenced somewhere.

What if the user chooses to open the form up again?

Why are you using static variables?

Perhaps you can provide a simple code sample?

– Dale

@dale ,
We replaced with static with instance variables now to fix the issues.
Can you please share sample github code for Plugin lifecycle events if available.
tried some Eto forms sample , were quite old and is there any new github repo for Eto forms plugin examples.


The ‘Closed’ and ‘closing’ event is triggered if you press the x-button. This is very similar/equal to how Windows Forms and WPF are working. Eto is just a multi-platform GUI wrapper. If you don’t know how to properly use Eto, which indeed is badly documented, then have a look at how things would work in these two GUI frameworks.

A Rhino command in comparison is really simple. As the name 'command’ implies, it just invokes a sequence of actions. Once it’s finished, it’s gone. Static fields obviously stay active, that’s why they are static. But declaring a static field inside a command is contradictory to its purpose, as @dale pointed out.

A singleton or even a service injected through a service provider is the right architecture to deal with problems of persisting information through multiple instances and types.

But before wildly guessing, isn’t it better if you post a minimal example?

Hi @nevin.mathew,

You’re right - we could use a few more Eto samples, as the ones we are are pretty basic.

Here is one that I pushed today that you’re welcome to review:


Note, this sample does not use a view model.

– Dale

thanks @dale