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 …
… 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,

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.)