General questions about listeners in Custom GH Components

I have been writing a lot of components with event listeners lately and I have a few general questions about implementation so that I can be aware of best practices.

  1. I have a lot of things that I typically need to update (trigger new component solutions) when a new Rhino document has loaded. Typically, I use the output of my custom RhinoDoc listener component to manually expire these downstream components. Take this example, for instance:

Here I am updating the Wombat “Get Document Units” component using my listener (offscreen) + MetaHopper. First question is this: Is it safe to write a document units component that incorporates its own document listener and use that instead? Is it safe to write a whole bunch of components that have their own internal document listeners and use them all over a large definition?

Is this conservative approach of using a single document listener in the document and manually expiring downstream components via Metahopper actually providing any safety/benefit? Because if not, I would probably be adding listeners of all kinds to a lot of my components. This holds true for layer events, viewport events, etc. I’m concerned about execution flow (and triggering multiple downstream operations/race conditions/invalid flags, etc), which is why I’ve been doing it this way. I realize that the gaps introduced by using Metahopper’s ExpireSolution everywhere has its own concerns, probably.

  1. After hours and hours of debugging various components, I became alarmed that the standard practice that I’ve been using for years essentially detaches and attaches a listener every time the component is solved, which isn’t a big deal for listeners that are “set it and forget it”, but for listeners that have selective expiration of outputs based on the event results and call ExpireSolution, I feel like there is way too much listener hijinx going on (see the preposterous SelectedLayersListener example I posted last week). Would you recommend storing the “Active” state in a static variable so that I can determine whether or not to remove/add listeners only when absolutely necessary? Or does it not matter?



@marcsyp This might not help the general scope of your post, but if you like, I can put your wishlist of events on our issue tracker and maybe get some of them into R7 (no promises!). While it seems you’ve already come up with a robust solution to some of these (layer selected listener?), there might be some benefit to us implementing it directly within Rhino.
Send me a list of things you want to listen to and I’ll get them up on youtrack.

Hi Luis – thank you!

The biggest one I can think of right now is an event raised when Rhino userdata + userdictionaries change, on Object, Layer, and Document levels. Right now I am manually expiring downstream components based on whether I am modifying user data, and it would be great to eliminate that infrastructure by allowing components to update themselves when a change comes in.

I’ll add others to this thread if I think of them!


1 Like

This can be tracked here: