Re: How do you build GUIs in Smile? (was Re: Plotting question)
Re: How do you build GUIs in Smile? (was Re: Plotting question)
- Subject: Re: How do you build GUIs in Smile? (was Re: Plotting question)
- From: has <email@hidden>
- Date: Thu, 22 Aug 2002 14:51:05 +0100
Andy Wylie wrote:
>
on Thu, 22 Aug 2002 18:13:25 +1000 Timothy Bates wrote:
>
>Yes: but how do use the thing? I can make a dialog, but I have no idea how
>
>to attach scripts to the items or what/how it generates events.
Building dialogs with Smile isn't terribly well documented as far as I can
tell. Bit of a pity, as I think it'd be a very good option for users who
need to build a quick and easy GUI frontend to their scripts, but don't
want to use Dialog Director [OS8/9 only and pretty horrible to use (imo)]
or ASS [slow to develop in and major overkill for many tasks; best suited
to complex, standalone shrinkwrapped applications]. It's an incredibly deep
application, highly expandable/modifiable and much more than "just another
script editor".
(It's no shoe-in for Hypercard as was suggested, mind you; but then it's
not supposed to be.)
Now, as for the mechanics of Smile dialogs: the actual implementation isn't
entirely brilliant imho, but quite usable...
--
First thing to realise is that although all objects in Smile are attachable
(i.e. you can hook a script to it), attaching code to dialog widgets won't
actually do anything as all widget events are passed directly to the dialog
window. So the only thing you attach a script to is the dialog itself.
--
Second, you'll find a list of the events you require in Smile's dictionary.
You have to read carefully: AS dictionaries don't unfortunately distinguish
between the messages that you'd normally send to the app (e.g. 'check
syntax') and the messages that the app sends for _you_ to handle (e.g.
'click in'). So you have to work out which is which from reading the
descriptions. (Looking at the event handlers in existing dialogs' code will
also help you here.)
--
Third (and this one particularly peeves me, although working around it is
straightforward enough), rather than passing a reference to the widget that
sent the message (or even just its name), Smile just hands you a simple
index number that matches the index of the widget as seen in the dialog.
The problem here is that index numbers 1. are liable to change as you edit
the dialog layout, and 2. make for horribly non-self-explanatory code
(which in turn increases the chance of making errors as you write/modify
the thing). Hence, I offer you a very simple rule of thumb which I do
recommend you adhere to:
* NEVER use literals when referring to your dialog's widgets. Ever. *
i.e. The following approach should be avoided like the plague:
on click in theDlog item number i
if i = 1 then
...
else if i = 2 then
...
or:
set contents of dialog item 3 to newValue
Though these constructs may look harmless enough it is actually
horrendously evil and vicious, and will contrive to make your life a misery
should you fall for it. Instead, define your own 'constants' up-front:
property dwUpdateButton : 1
property dwRevertButton : 2
property dwTitleTextField : 3
and use those throughout your code instead:
on click in theDlog item number theWidget
if theWidget is dwUpdateButton then
...
else if theWidget is dwRevertButton then
...
and:
set contents of dialog item dwTitleTextField to newValue
[The 'dw' ("dialog widget") prefix is up to you; I prefer treating these
special-purpose properties as a coherent group, and a naming scheme makes
this clear.]
Now, I know even the Smile folks themselves do it the other way, but it's
bad technique and it _will_ bite you sooner or later, as well as making
life needlessly difficult in the meantime. It's not hard to make your code
compensate for the environment's own weaknesses, and it'll quickly become
second nature.
Oh, and should you subsequently edit your dialog's layout with the result
that its widgets are renumbered, you'll be able to update your own code to
match in a couple of seconds, while testing those changes will take about
the same amount of time. This is a hundred times easier than playing "hunt
the numbers" right throughout your code, not to mention testing the
resulting changes (which will require a comprehensive thrashing of every
code path to ensure you haven't left so much as a single index number
accidentally unchanged or accidentally changed another number that you
shouldn't have).
--
Lastly, I'd also suggest you put as little code into your 'click in', etc.
handlers as possible: it makes it much harder to write and test. Instead,
put the bulk of your code into its own handlers, and reduce the 'click in'
handler to nothing more than a simple if...elseif block and a bunch of
calls to your own functions.
on click in theDlog item number theWidget
if theWidget is dwUpdateButton then
clickedUpdateButton(theDlog)
else if theWidget is dwRevertButton then
clickedRevertButton(theDlog)
else if ...etc.
...
end if
end click in
You might think this is a lot of unnecessary bloat and bother, but trust me
on this: it will make your code much simpler to write, debug, modify and,
perhaps most importantly, read.
--
--
(My email address has changed from <email@hidden> to
<email@hidden>. Please update your address books accordingly.)
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.