Grasshopper

algorithmic modeling for Rhino

Event unsubscription - correct locations to prevent duplicate subscription

Hello,

I have a simple but surprisingly puzzling question. 

When subscribing to events in the body of SolveInstance often duplicate subscriptions are registered (for example when new solutions are generated).  

What is the best place to unsubscribe from an event or better yet what is the best method for preventing duplicate subscriptions as new solutions are generated?

Views: 366

Replies to This Discussion

If I can't be certain when a handler is registered with an event, then I always unsubscribe first. Though ideally you'd know to only register a handler once. An alternative solution is to maintain a local variable:

private bool _handled = false;

...

if (!_handled)

{

  _handled = true;

 someEvent += MyHandler;

}

The first suggestion looks like this:

someEvent -= MyHandler;

someEvent += MyHandler;

David,

I absolutely agree with your strategy.

Maybe I'm looking at this the wrong way but here is a test component (attached) that subscribes to the following events:

DocumentServer_DocumentRemoved

DocumentServer_DocumentAdded

Instances_CanvasCreated

Instances_CanvasDestroyed

DocumentEditor_FormClosed

If the component is loaded (for example by opening it's canvas) and then unloaded (for example by closing it's canvas), the events are subject to being loaded multiple times.  Perhaps you can take a quick look at this to confirm I'm not incorrect.  I've spent a day on this but am totally stumped about the duplication.

I'm watching for multiples by triggering a MesasgeBox - if you see what I see you'll get several repeats, with more occurring as you reload and destroy a canvas.

Attachments:

CanvasCreated and CanvasDestroyed are usually only called once. One time when the Grasshopper window is first loaded and then again upon successful closing of Rhino. The GrasshopperUnloadPlugin command may also trigger these events, but that is almost exclusively used by developers doing debugging.

I won't have time to look at the code until tomorrow evening at the earliest.

Exactly what events do you need to handle and why? Your component class getting constructed? Your component class being placed into a new document? Your component class being deserialized into a document? The document containing your component class being loaded into the active canvas?

David,

I've been working on all of this for the entire day and am just wrapping up now. I think I've found the answers I need and most things are working but I'll double check again tomorrow with a clear head and write if I have any questions.

If I recall correctly from my earlier tests the events would duplicate despite a prior unsubscription when making new documents or closing documents as well as unloading the canvas via the "GrasshopperUnloadPlugin" command. 

That all said you might be right that this is minor enough to ignore. I will certainly let you know if I run into any other problems tho.

Appreciate your help.

Why I'm using these events - to ensure that a call to the display pipeline reflects the state of the canvas per user desires to change documents etc.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service