Modify Document in OnEndOpenDocument (C++)


(Luke Niwranski) #1

Hello,

I’m managing a plug-in that was developed for Rhino 4.0. It has code that modifies a document in a number of event watchers. I’ve noticed that in the Rhino 5 SDK, there are numerous comments stating not to do so, and to instead use an CRhinoIsIdle event class instead. This class, however, does not exist for Rhino 4, and I’d like to maintain backward compatibility.

What are the implications of modifying a document in the OnEndOpenDocument event watcher in Rhino 4 and 5? Is there a better way to modify the document from this event while maintaining backward compatibility with Rhino 4?


(Dale Fugier) #2

Hi Luke,

Our event watcher class is poorly worked. Is really should be labeled as an event notifier.

When using our event watcher class, when you detect an event, you should set a flag of some kind (denoting that the event has occurred) and then quickly return out of your handler.

Then at an appropriate time, such as when one of your commands run, check the flag and, if dirty, take the appropriate action. This is referred to as lazy evaluation. By doing this, Rhino will run quickly (as others might be watching the event too) and the risk of crashing Rhino will be reduced (again, as other might be watching the event and, thus, also incorrectly modifying the document).

Does this help?


(Dale Fugier) #3

Hi Luke,

Our event watcher class is poorly worked. Is really should be labeled as an event notifier.

When using our event watcher class, when you detect an event, you should set a flag of some kind (denoting that the event has occurred) and then quickly return out of your handler.

Then at an appropriate time, such as when one of your commands run, check the flag and, if dirty, take the appropriate action. This is referred to as lazy evaluation. By doing this, Rhino will run quickly (as others might be watching the event too) and the risk of crashing Rhino will be reduced (again, as other might be watching the event and, thus, also incorrectly modifying the document).

Does this help?


(Luke Niwranski) #4

Hi Dale,

Yes a little. Lazy evaluation will work for some aspects of the plug-in, but not others. One example that comes to mind is loading documents that contain plug-in data. The data written to .3dm files has changed recently, and to maintain backward compatibility, I need to be able to look up Rhino objects by UUID after the document has been loaded and process the geometry to correctly build our internal data structures. Without doing this, some of our highlights and visual aides do not display. Even though the processing isn’t necessary for our plug-in to operate, not having the visual feedback just looks like the plug-in isn’t working, or the loaded file doesn’t contain an expected feature.

If Rhino 5 has a working idle notifier, I’d be happy with simply splitting the plug-in in to strict Rhino 4 and Rhino 5 versions. Do you have an example of how to use the Rhino 5 CRhinoIsIdle class? Also, is there any way I could finagle similar functionality in Rhino 5? Is there any method or member in CRhinoApp, CRhinoDocument, or CRhinoPlugIn that I’ve overlooked that I can check to see if Rhino is currently idle? If so, I can probably just create a thread to periodically check this value and use this as the basis for my own idle task manager for Rhino 4.


(Dale Fugier) #5

Here you go:

https://github.com/mcneel/Rhino5Samples_CPP/blob/master/SampleCommands/cmdSampleIdleProcessor.cpp

I’m assuming you mean Rhino 4, to that the answer is no.

– Dale


(Luke Niwranski) #6

Yes, sorry, I did mean Rhino 4.

Thank-you very much for the example!