Scripting & Custom Interface

[Prochazka, Victor (ott)]

> ----------
> From: 	creator-bounces at wacondatrader.com on behalf of chris denesha
> 
> I haven't played with user palettes yet but I can think of two
> possibilities from a programming standpoint - have you experimented with
> them?
> 
> 1) Use code to check for the response from the dialog box - if it is
> Cancel (or perhaps if it isn't OK, depending on whether you have a default
> button) and either prevent the palette close or reopen it
> 
> 2) Trap an event that tells you it is about to close - looking in the
> dictionary there is a 'request to close' callback event under Custom
> Interface with a description that might help.
> 
Thanks for the suggestions Chris.  I tried to catch the "Cancel" as a
response, but it still closed the palette afterwards. I already use a
"request to close" handler to save some prefs, so I wouldn't want to prevent
someone from legitimately closing this palette.

Steve's solution was the best for this scenario. The On Error handler works
like a charm!

Thanks all,

-Vic
The Ottawa Citizen

> ----------
> From: 	creator-bounces at wacondatrader.com on behalf of Steve Mills
> 
> Both sound like viable options, but there are 2 different things  
> happening; clicking the close box, and clicking the Cancel button in  
> the warning dialog (which is falling through and telling the entire  
> script to cancel, I believe).
> 
> If you're using "display dialog" for the warning, you can trap the  
> Cancel button like so:
> 
> try
> 	display dialog "bob" buttons {"Cancel"} default button "Cancel"
> on error err number num
> 	if num is -128 then
> 		say "cancelled"
> 	else
> 		--Pass on other errors:
> 		error err number num
> 	end if
> end try
> 
> Or if you're using a "user dialog" for the warning, you'll get the  
> clicked button returned from "run dialog modally".
> 
> But in the end, installing a "request to close" handler sounds like  
> the thing to do for handling the palette's close box.
> 
>