SU 2019 Win view observer delayed (added from C)

I see a delay in getting view observer events in SU2019.
For some reason the observer doesn’t trigger immediately, but fires up after entering/leaving a group or component.
It looks like something is holding up all the onViewChanged() events and spilling them out afterwards.

Does anyone see similar thing? I set the view observer from C Ruby extension - I am calling Ruby function from there.

When I created a minimal sample in pure Ruby everything works fine, so I think it has to do with the call from C.

Mac or Win?
On Win can’t see any differences.

It is Win. Mac works fine.
It looks I will have to modify the C extensions example to replicate the issue to share it here.

I call AddObservers() Ruby function from C using:
In the Ruby function I do:

Is there an open operation? Since SU2016 observer event’s that happens during an operation is deferred until the end of the operation.

Can you provide a complete example to repro? At least the complete source code. (We can insert the C code into the Ruby C Extension example we have on github)

Tomasz … please read the release notes for Observer changes in v2016 …
File: Release Notes — SketchUp Ruby API Documentation
… and the PDF document …

The “hold and spill afterward” I see with a lot of the ToolsObservers especially.

Keep in mind that there is still an issue in su observers:

@tt_su have you changed anything about this in 2019.2?

No, we haven’t made any explicit changes to observers for SU2019.x.

The documentation states otherwise …

  • Prior to SketchUp 2019.2 this event did not trigger when the viewport size changed.

At least (based on changelog) there are two changes that can affect onViewChanged() observer:

1). Updated Ruby from 2.5.1 to 2.5.5 to address a logic bug in Ruby
2). As Dan mentioned, onViewChanged doesn't trigger when viewport changes size · Issue #200 · SketchUp/api-issue-tracker · GitHub

Strange that it works for .1 and doesn’t work for .2, but without an example we won’t find out why.

Thank you for all suggestions.

I have to spend more time on it to tell what is going on. Could it be related to linking with sketchup.lib? I have made a lot of changes in the code to migrate from C++ to C SDK, but I didn’t touch the observers in the process.
I also noticed that when I added a “minimal view observer” plugin, then my original function also started to receive the event immediately.

I meant in the fundamental way of how they are dispatched, like we did in SU2016.

1 Like

I don’t really see the C API having a relevance. Because you are using the Ruby API after all here - even if it’s from a Ruby C extension.

From Ruby C?

No, the “minimal” observer is added purely from Ruby.

I will revisit this issue again on Monday.

Uhuh, but I also implied that someone was into the ViewObserver code last cycle, and an error could have been introduced. (You know how goes.) :wink:

While chasing the issue, I found one thing that may be related.
I really do not understand why C API copies a behavior of Ruby function for getting an attribute dictionary. A “getter” should be just a function that gets something and does not create it when it is missing. It is especially dangerous in a case of live C API, that we are not supposed to use for modifying a live model.


Retrieves the attribute dictionary of an entity that has the given name.
If a dictionary with the given name does not exist, one is added to the entity.

If a developer is using it just to read the dictionary, as naturally expected, then it will be modifying the live model in many places, producing unnecessary dictionaries throughout a model.

There is SUEntityAddAttributeDictionary() so why adding this automatically??
Are there many things like this in C API?

1 Like

I wasn’t aware of that. That was implemented long before my time at SketchUp.

I’m not a fan of such side-effects either.

Arrgghh… I have wasted so much time on this.
I confirm. The issue was caused by

When called - it destroys the dispatch of observers events!

In Ruby we have attribute_dictionary(name, create = false):

The default is false! Why it is different in C API? Why does it modify model when nobody expects it to?

This is a mistake in C SDK.

Reported here:

1 Like

I’m not sure. This function was added before my time.

Agree - bad API design. Getters should not have side effects like this.

I wonder if anyone is actually relying on the current behaviour. I don’t like breaking API behaviour, but in this case I’m leaning to consider it a bug and removing behaviour.

1 Like

It would have been better if the creator function created a dictionary if it did not exist, otherwise just returned it if it did, … rather than have a getter default to creation. (Ie, the getter often doubles as a query to see if a collection has a certain member.)