Close webdialogs on File-New/Open

thomthom

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.