V8, RhinoCommon, DocumentPropertiesChanged Firing Too Often?

Rhino Developer
1
  1. Is Rhino supposed to be firing DocumentPropertiesChanged when you open File->Properties and/or click between ‘tabs’ of the Properties form, not yet having changed anything?
  2. it seems to be firing a lot more times per UI stimulus than I expect (which would be once).

(2) could be a plugin bug if the instantiation is wrong and creating extra instances but this is prpetty close to a from scratch plugin based on the Utility one created by the Studio plugin- code attached.

I still wouldn’t have expected it to fire so often when the properties are just being viewed, not changed: it does fire upon clicking OK after edits which is what I expected.

I noticed this because I trigger view updates when the event fires and they were happening often enough to slow things down.

I had to reduce the screensize to get the attachment under 20MB. What I click at the end and get one more round of event firings is the OK button, not cancel. The start of the video is just a blank document but I don’t think that’s related.

propertieschanged.zip.zip
(290.4 KB)
systeminfo.txt (2.5 KB)

Edit: slight change of phrase on point 2 to make it clear within that point that it seems to firing x times per UI click, not once.

2

Bump. That code event seems to be firing many times per actual UI reason to fire, plus firing too soon.

3

Hi @Nathan_Bossett,

I can see that. I’ve logged an issue so I can investigate.

https://mcneel.myjetbrains.com/youtrack/issue/RH-79494

If your event handling is structured property, then the number of events shouldn’t matter.

When a DocumentPropertiesChanged is triggered, set a flag indicating such.

When Rhino goes idle, then process the event.

I’ve attached a sample for you to review.

TestDocumentPropertiesChanged.zip (26.1 KB)

Thanks,

– Dale

4

Thanks.

Yes, thanks.

I reported it mainly because it seems like an easy way for plugins to inadvertently slow Rhino down (running a calc or refresh 8x instead of 1x)- that’s how I noticed it.

Plus, it can result in the plugin deciding it needs to recompute or refresh the display when the user wound up canceling instead of OKing out of the Properties window so there was actually nothing that needed to be done.

Thanks again!