Close webdialogs on File-New/Open
-
Is there a way to observe if the user opens a new or existing file so the open webdialogs can be closed?
-
You shouldn't need an observer if the tool-class calling the dialog [
@dlg
] has adeactivate()
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 settrue
/false
as you open and then close the dialog@dlg
.
If you have closed the dialog in the Tool then later callself.deactivate()
etc...
You should also use it in theonCancel()
method too...
Alternatively the code
begin @dlg.close rescue end
does it trapping errors for you in thedeactivate()
???
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. -
@tig said:
You shouldn't need an observer if the tool-class calling the dialog [
@dlg
] has adeactivate()
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 -
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? -
-
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
-
Beware that on OSX you can have multiple model documents open.
-
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. -
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.
-
sssshtttt ThomThom,
you're giving me a headache on a friday afternoon
-
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... -
@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.)
-
@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. -
Agreed.
I logged several Feature Requests for MDI support (new methods) in the API, including a Models collection.
Advertisement