sketchucation logo sketchucation
    • Login
    ℹ️ Licensed Extensions | FredoBatch, ElevationProfile, FredoSketch, LayOps, MatSim and Pic2Shape will require license from Sept 1st More Info

    State of Observers — 28 February 2010

    Scheduled Pinned Locked Moved Developers' Forum
    38 Posts 12 Posters 16.5k Views 12 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • thomthomT Offline
      thomthom
      last edited by

      Yea - pretty sure so - because .add_observer also returns true/false . You need to keep a reference to the actual observer instance.

      Thomas Thomassen — SketchUp Monkey & Coding addict
      List of my plugins and link to the CookieWare fund

      1 Reply Last reply Reply Quote 0
      • AdamBA Offline
        AdamB
        last edited by

        @adamb said:

        Yes, I can confirm its a repeatable bug on Mac OSX SketchUp 8.

        I've logged a very grumpy bug report with Google.

        Useful to know you can stop the crash by saving before exiting, but I am disappointed a bug like this could be missed. I know software has bugs in it etc, but this seems like any basic regression testing / smoke testing would flush this one out.

        After I'm done with a Tool, I always done .pop_tool rather than .select_tool(nil) because it seems less presumptuous. ie restore what the user was doing before rather than cancel their previous selection.

        However, Gaieus found out a problem/conflict with Jim Toolbar Organizer - long story short, I've switched to doing select_tool(nil) to avoid some weird race-condition with menu validation procs.

        But it seems to have cured the crash on exit of SU8 on Mac when using Observers as well...

        Adam

        Developer of LightUp Click for website

        1 Reply Last reply Reply Quote 0
        • thomthomT Offline
          thomthom
          last edited by

          @adamb said:

          After I'm done with a Tool, I always done .pop_tool rather than .select_tool(nil) because it seems less presumptuous. ie restore what the user was doing before rather than cancel their previous selection.

          However, Gaieus found out a problem/conflict with Jim Toolbar Organizer - long story short, I've switched to doing select_tool(nil) to avoid some weird race-condition with menu validation procs.

          But it seems to have cured the crash on exit of SU8 on Mac when using Observers as well...

          what? damn! I rely on this feature for a plugin I'm making. what kind of race condition? you got a small example?
          windows, osx?

          Thomas Thomassen — SketchUp Monkey & Coding addict
          List of my plugins and link to the CookieWare fund

          1 Reply Last reply Reply Quote 0
          • AdamBA Offline
            AdamB
            last edited by

            Ok, it appears to be that if you select_tool but then pop_tool, things can get fubar.

            Mostly its benign - hence I got away with it - but with the LargeToolSet showing from Jim's Tool Organizer, the additional calls to the validation procs reveal the error. In that it is wrong to be selecting a tool then popping it, but you might hope SU would just ignore it.

            The attached Ruby is a simple Tool that always performs pop_tool on keypress Escape.

            It can be invoked either by calling "baddoit()" which starts it using select_tool, or by calling "evian()" which starts it using push_tool.


            poptool.rb

            Developer of LightUp Click for website

            1 Reply Last reply Reply Quote 0
            • thomthomT Offline
              thomthom
              last edited by

              Ok, so:

              select_tool + pop_tool = fubar
              but
              push_tool + pop_tool = OK
              ❓

              Thought I'd tried pop_tool with select_tool before - without pop_tool doing anything. Thought it only worked after push_tool.

              Thomas Thomassen — SketchUp Monkey & Coding addict
              List of my plugins and link to the CookieWare fund

              1 Reply Last reply Reply Quote 0
              • AdamBA Offline
                AdamB
                last edited by

                @thomthom said:

                Ok, so:

                select_tool + pop_tool = fubar
                but
                push_tool + pop_tool = OK
                ❓

                Thought I'd tried pop_tool with select_tool before - without pop_tool doing anything. Thought it only worked after push_tool.

                Not quite. select_tool + pop_tool = fubar isn't always terminal. Just apparently if there are really large toolbars around hence its never caused a problem for me in the past.

                Thomthom, can you get Jims' Organiser thing and see if you can repro this.

                Developer of LightUp Click for website

                1 Reply Last reply Reply Quote 0
                • thomthomT Offline
                  thomthom
                  last edited by

                  Size of toolbars matter?
                  Or is it toolbars with validation procs?

                  I have Jim's plugin installed on my Sy7 installation. Is it a particular pre-set toolbar that should be tested against?

                  Thomas Thomassen — SketchUp Monkey & Coding addict
                  List of my plugins and link to the CookieWare fund

                  1 Reply Last reply Reply Quote 0
                  • Dan RathbunD Offline
                    Dan Rathbun
                    last edited by

                    @adamb said:

                    After I'm done with a Tool, I always done .pop_tool rather than .select_tool(nil) because it seems less presumptuous. ie restore what the user was doing before rather than cancel their previous selection.

                    However, Gaieus found out a problem/conflict with Jim Toolbar Organizer - long story short, I've switched to doing select_tool(nil) to avoid some weird race-condition with menu validation procs.

                    This issue is caused by the tool stack having no tool_id (or more precisely Tools.active_tool_id == 0 ).

                    @unknownuser said:

                    (http://code.google.com/apis/sketchup/docs/ourdoc/tools.html#active_tool_name)":u0sru3py]NOTE: Calling active_tool_name on an empty Tools collection might cause a crash. Before calling this method, it is important to check whether or not the Tools collection is empty. The Tools collection is empty if the method .active_tool_id returns zero.

                    So always check if tools.active_tool_id==0 before using .pop_tool() or .active_tool_name()

                    I'm not here much anymore.

                    1 Reply Last reply Reply Quote 0
                    • Dan RathbunD Offline
                      Dan Rathbun
                      last edited by


                      onQuit() callback


                      I have noticed that on SU 8.0M1 (at least,) that Sketchup does not wait until the callback returns, before it closes all it's child and owned popups, and it's own app window and shuts down.

                      You can still have code in an onQuit() callback running after all Sketchup's windows have closed. (You can try it with a messagebox.)

                      I was trying to save size and position of some windows, but Sketchup closes all it's windows before my onQuit() callback code can use Win32API calls to grab the window sizes. I even 'leaned' the code out as much as possible, but still to no avail, ... my code writes empty size arrays into the registry.

                      My next choice will be to try and use Ruby's built-in define_finalizer for one of my objects, perhaps the plugin module, or the observer object, .. and see if Sketchup will wait until the finalizer block returns.

                      Did anyone notice this behaviour in SU 7.x ?

                      I'm not here much anymore.

                      1 Reply Last reply Reply Quote 0
                      • Dan RathbunD Offline
                        Dan Rathbun
                        last edited by

                        Quick Question ...

                        Seems I remember that AppObserver::onNewModel does not get called when Sketchup starts up.

                        Is this generally true.. or specific to PC or Mac ?

                        I see the API says that a command line skp file will not fire the onOpenModel() callback.

                        I'm not here much anymore.

                        1 Reply Last reply Reply Quote 0
                        • thomthomT Offline
                          thomthom
                          last edited by

                          @dan rathbun said:

                          Seems I remember that AppObserver::onNewModel does not get called when Sketchup starts up.

                          Is this generally true.. or specific to PC or Mac ?

                          Aye.

                          Thomas Thomassen — SketchUp Monkey & Coding addict
                          List of my plugins and link to the CookieWare fund

                          1 Reply Last reply Reply Quote 0
                          • 1
                          • 2
                          • 2 / 2
                          • First post
                            Last post
                          Buy SketchPlus
                          Buy SUbD
                          Buy WrapR
                          Buy eBook
                          Buy Modelur
                          Buy Vertex Tools
                          Buy SketchCuisine
                          Buy FormFonts

                          Advertisement