Detect scene activation

DanRathbun · March 27, 2019, 3:48pm

Yes I had implemented an abstract class page in the docs for this several years ago …

API FR filed (Jan 2018 Issue #26): … add any thoughts to issue please.

github.com/SketchUp/api-issue-tracker

PagesObserver#onPageUpdate() observer callback

opened 03:10PM - 17 Jan 18 UTC

DanRathbun

enhancement Ruby API SketchUp logged

### SketchUp Ruby API Feature Request The API is missing an `onPageUpdate()` …observer callback. Tests show nothing firing when a page is updated. I attached a test observer to the page, the pages collection and the entities collection. Got no response. **1. Use-case:** One case is what is described in Eneroth3's FR: https://github.com/SketchUp/api-issue-tracker/issues/25 When a page update callback fired, she could check her extension's data to sync it with what the page is doing with the view's properties, ... **camera**, **section planes**, etc. **2. Suggested pattern / parameters:** **One** pattern of arguments passed into the callback **could** be: **`pages, page, old_flags, new_flags`**. It would make dealing with changes much better if the flags prior to the update could be compared with the new flags. **ADD**: This would be a bulk callback pattern where 1 call would be made after a scene page update. If this pattern is chosen, the flags would be st be passed as hash arguments as described [below in post 5](https://github.com/SketchUp/api-issue-tracker/issues/26#issuecomment-691034098) ... ```ruby def onPageUpdate(pages, page, old_flags, new_flags) if old_flags != new_flags # The page property set changed ! changed = (old_flags - new_flags).abs end end ``` **OR**, ... ... another pattern of arguments passed into the callback **could** be: **`pages, page, property, old_value, new_value`**. This would be an individual callback pattern where a call would be made **for each changed property**, **either** after a scene page update ... or **immediately after** the actual change of an individual property or update flag. In this scenario the callback name does not need to reflect "update" as there are several properties that can change independent of an update, which have no current observer firing (or that helps identify the page and property that changed. Ie [`PagesObserver#onContentsModified`](https://ruby.sketchup.com/Sketchup/PagesObserver.html#onContentsModified-instance_method) fires for some changes but does not pass the reference of the page whose property changed, nor the property that changed, making the firing almost worthless to coders. _[See list below for details](https://github.com/SketchUp/api-issue-tracker/issues/26#issuecomment-691744240)_.) So given this (and the fact that [`EntityObserver#onChangeEntity`](https://ruby.sketchup.com/Sketchup/EntityObserver.html#onChangeEntity-instance_method) does **not** fire at all for scene page entity objects (when it should have,) it might be better to name the callback `"onPageChanged"` ... ... and have it fire for changes to: `:name`, `:description`, `:delay_time`, `:include_in_animation`, `:transition_time`, _etc._, **in addition to** the update flags (and _possibly_ the page's **position** in the collection as [`PagesObserver#onContentsModified`](https://ruby.sketchup.com/Sketchup/PagesObserver.html#onContentsModified-instance_method) fires **once** when a page's position is changed but doesn't give any info to determine which page was moved, and what other pages had their positions adjusted accordingly.) ```ruby def onPageChanged(pages, page, property, old_value, new_value) if property == :use_axes && new_value # The axes is being saved, so ... MyPlugins::AxesHistory.save_axes(page.name, page.axes.transformation) end end ``` **2. Suggested implementation / reasoning:** I think it best that this callback be added to the **[`Sketchup::PagesObserver`](http://ruby.sketchup.com/Sketchup/PagesObserver.html)** class documentation, as that is where coders will be looking for it. (Yes observers are abstract now, but this is about where coders "attach" observers, see below) This is also where they are likely to wish to attach such an observer. (It is tedious to be forced to attach an observer to each item in a collection, so I'd vote **against** putting this in the [**`Sketchup::EntityObserver`**](http://ruby.sketchup.com/Sketchup/EntityObserver.html) class, which would force coders to attach to each and every page instance. **Ie, SketchUp should poll the observers attached to the collection for a callback method, instead of the _possibly many_ observers attached to the page entity itself.** (Easier and faster for everyone!) ~