Close webdialogs on File-New/Open

Pout

Is there a way to observe if the user opens a new or existing file so the open webdialogs can be closed?

TIG

You shouldn't need an observer if the tool-class calling the dialog [ @dlg] has a deactivate() method which includes @dlg.close if @dlg and @dlg_is_open or equivalent. Exiting the tool then closes the dialog if it has been set up initially and is still 'open'. The instance variable @dlg_is_open can be set true/ false as you open and then close the dialog @dlg.
If you have closed the dialog in the Tool then later call self.deactivate() etc...
You should also use it in the onCancel() method too...
Alternatively the code
begin @dlg.close rescue end
does it trapping errors for you in the deactivate() ???
Of course on a PC opening your dialog so it is 'modal' with '@dlg.show_modal{#what_to_do#}' prevents you even exiting the Tool or the SKP until the dialog is closed itself.

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.