Unload / reload plugin without closing SketchUp
-
@tig said:
but I see little benefit unless their normal use is done obscurely, since access to the commands will be via toolbars/menus etc that can be disabled...
Ditto. For the end user - as long as your plugin deactivates all observers - the only thing that will bother them is the menus and toolbars. I would have just focused on making them clearly display the disabled state of the plugin.
-
I also note that you refer to using
EntitiesObservers- these are well known for causing issues. https://developers.google.com/sketchup/docs/ourdoc/entitiesobserver@unknownuser said:
WARNING: The methods of this observer fire in such a way that making changes to the model while inside of them is dangerous. If you experience sudden crashes, it could be because of this observer. A potential workaround is to use a ToolsObserver to watch what the user is doing instead.
So using an alternative IS recommended/possible...
If they are only attached during the very operation of you tool then maybe they'll be OK, but if they 'persist' into the operation of normal Sketchup then they can cause other innocent tools to crash, because they are then seen to be somehow changing the model's entities while the observer is active... I had an issue with one of my tools crashing because of a 3rd party tool made such an observer that persisted. I recoded to erase only the unwanted groups etc by using .clear! on their entities, so that the closing commit_operation cleaned up, rather than directly erasing them inside the start/commit block [which activated the crash]... Of course scripts should be allowed to do legitimate operations without fear of falling foul of someone else's ill-considered observer...
Indeed it was found that even a completely 'empty' EntitiesObserver will cause such unexpected crashes, if it's left active during the operation of some other tool that innocently changes the entities within a start/commit block. -
@tig said:
So using an alternative IS recommended/possible...
Hmmm, I already changed "SelectionObserver.onSelectionAdded" to "SelectionObserver.onSelectionBulkChange" because of a warning like that.
I will try to get rid of that one too!
But this is probably the most important to be able to disable all observers.
And yeah, maybe it's enough to just have a disable-observer button instead of trying to unload the entire plugin. If someone really wants it completely disabled then the unload-extension feature(with restart) can always be used(and is probably the only thing that makes sure it's completely unloaded).
-
@brewsky said:
And yeah, maybe it's enough to just have a disable-observer button instead of trying to unload the entire plugin. If someone really wants it completely disabled then the unload-extension feature(with restart) can always be used(and is probably the only thing that makes sure it's completely unloaded).
Yes. Keep track of your observers (and try to make them do as little as possible) and ensure you remove them all when not needed.
When I need to use observers I try to make them as light as possible - simply keeping a cache of the info I get from the observers (unprocessed) - then at safe points I process and react on them. -
Btw, have you seen this list: http://www.thomthom.net/software/sketchup/observers/ ?
-
@thomthom said:
simply keeping a cache of the info I get from the observers (unprocessed) - then at safe points I process and react on them.
You mean like, create an array of "objects that need to be updated", and process the array seperately(like once a second with a timer)?
Thanks for the list, I will try to pick the least buggy ones
-
@brewsky said:
You mean like, create an array of "objects that need to be updated", and process the array seperately(like once a second with a timer)?
No - not like a timer, because that might trigger in the middle of another operation, just like observer events. But just in time before you need to.
(Hard to give specific examples when I don't know how your plugin works.)Ideally we would have an observer event for when an operation completed - but alas.
-
@thomthom said:
(Hard to give specific examples when I don't know how your plugin works.)
I am using 2 kinds of objects:
- source objects (faces)
- geometry objects, like walls (groups)
When a source face is moved the wall needs to be re-drawn to match shape and position.
Check out this video(around 1:30): http://www.youtube.com/watch?v=J59EgH7LICs
The plugin will probably work best when the update is fired immediately...
-
@brewsky said:
When a source face is moved the wall needs to be re-drawn to match shape and position.
Problem is, if you modify the model on an entities event you might interrupt an existing process. Some other tool might be causing your observer to trigger in the middle of it's operation. That would either prevent it from completing or at worst crash SketchUp
I ran into lots of these problems myself a while ago when I tried to make a plugin reacting to observer events: http://sketchucation.com/forums/viewtopic.php?f=180&t=19011#p155886
You're running into the same type of issue as what I did, and also what Dynamic Components are doing. I talked to Scott about what he did to solve the matter. He said he used various observers to find safe points to react to. A key observer was the Tools observer, checking for the change of state with tools. They can usually be translated into operation commits and - possibly safe. I think he observed the Tools stack for when the native Move, Rotate and Scale tool completed.
-
@thomthom said:
I talked to Scott about what he did to solve the matter. He said he used various observers to find safe points to react to.
Thanks! Won't be easy to get it entirely stable I guess...
The "disable observers" button is probably a good starting point.
But I think it will need a lot of re-structuring before I have figured that out in it's entirety. -
Yea - the key is that you're plugin is not the only one operating and observer events can trigger in the middle of other operations. That's why I talked about caching the observer data until you find a "safe point" to execute. Mapping out this is important to avoid headache. Keeping observers to a minimum is best IMO - reduces overhead and risk of conflicts. Consider each observer if you really need it.
I'm a bit more liberal with observers when I use them within the operation of my own custom Tools. (Within a Tool class) as I then assume I have greater control over the environment.
Advertisement