Close webdialogs on File-New/Open

[thomthom]

@tig said:

You shouldn't need an observer if the tool-class calling the dialog [ @dlg] has a deactivate()

That's assuming the webdialog is opened by a tool. If it isn't, then it's the AppObserver one has to use: http://code.google.com/apis/sketchup/docs/ourdoc/appobserver.html

[Pout]

It's like this:
The webdialog is opened though a button and shows info on the Sketchup model.
Straightforward, no class used.
So i think it's the AppObserver i need.
I have to initiate that at the start of the ruby and just handle the events?

[thomthom]

@pout said:

I have to initiate that at the start of the ruby and just handle the events?

Yup!

[TIG]

class MyDialogAppObserver < Sketchup;;AppObserver
  def onNewModel(model)  ### from menu or app
    begin
      $myDialogID_12345.close
    rescue
    end
  end
  def onOpenModel(model) ### from menu
    begin
      $myDialogID_12345.close
    rescue
    end
  end
  def onQuit()
    begin
      $myDialogID_12345.close
    rescue
    end
  end
end
### Attach the observer at kick-off...
Sketchup.add_observer(MyDialogAppObserver.new)

You then need to set a global variable referring to your dialog [ dlg] so the observer can find and close it...
$myDialogID_12345=dlg

[thomthom]

Beware that on OSX you can have multiple model documents open.

[Pout]

Tig, thx for the piece of code!
ThomThom, in that case it think it will be necessary to keep the model path in a global variable and use that to check.

[thomthom]

And if the user swaps between models while working?
Or the user saves the model under a new name?

I have a tool where I need to keep track of the various models. I tried using the model object as reference, but it changes when you save teh model etc. I also tried the model.guid - but that also changes at times. At the moment I use a combo of model object and guid to track it.

[Pout]

sssshtttt ThomThom,

you're giving me a headache on a friday afternoon

[TIG]

Why not make a simple tool that opens the dialog and then you can have a 'deactivate()' method to close the dialog whenever you move away from that SKP ? - you'd just need to wrap the original 'def' code into an initialize()/activate() instead, inside the new tool's class and call the 'tool' in a slightly different way from a raw 'def' ??
Adding convoluted observers and global variables seems to be a lot more complicated...

[thomthom]

@tig said:

Why not make a simple tool that opens the dialog and then you can have a 'deactivate()' method to close the dialog whenever you move away from that SKP ? - you'd just need to wrap the original 'def' code into an initialize()/activate() instead, inside the new tool's class and call the 'tool' in a slightly different way from a raw 'def' ??
Adding convoluted observers and global variables seems to be a lot more complicated...

Then you can't use the other native tools.

(And I'd use module variables instead of global variables.)

[thomthom]

@pout said:

sssshtttt ThomThom,

you're giving me a headache on a friday afternoon

you're welcome.
The whole multiple window scenario under OSX is a bit of a pain - I don't feel it has proper support in the API for managing them.

[Dan Rathbun]

Agreed.

I logged several Feature Requests for MDI support (new methods) in the API, including a Models collection.