MIKEA%BROWNVM.BITNET@MITVMA.MIT.EDU (Michael J Antonio) (09/29/88)
The solution to Charles Allens problem about having to change n occurences of a script is easy. Put the action that you want to preform in the card or background script, in an "on fooBar" handler. Then put on mouseUp fooBar end mouseUp or whatever is the appropriate handler. Then you only have to change the fooBar script, and the others will be updated automatically. MikeA
cca@pur-phy (Charles C. Allen) (09/30/88)
In article <70621@sun.uucp>, MIKEA%BROWNVM.BITNET@MITVMA.MIT.EDU (Michael J Antonio) writes: > Put the action that you want to preform in the card > or background script, in an "on fooBar" handler. Then put > on mouseUp > fooBar > end mouseUp > or whatever is the appropriate handler. Then you only have to change the > fooBar script, and the others will be updated automatically. An example I gave did this. There are still two problems: * If the interface to the fooBar handler is changed (different parameters perhaps), then every occurrence still must be changed. * The mouseUp handler is still present in every button that uses this. Multiply by a couple of hundred cards with approximately 15 card buttons of this "class" (no they can't be background buttons). I want the script for those buttons in ONE place, not 3000. Charlie Allen cca@newton.physics.purdue.edu
borton@uva.UUCP (Chris Borton) (09/30/88)
In article <1482@pur-phy> cca@pur-phy (Charles C. Allen) writes: > * The mouseUp handler is still present in every button that uses > this. Multiply by a couple of hundred cards with > approximately 15 card buttons of this "class" (no they can't > be background buttons). I want the script for those buttons > in ONE place, not 3000. It's not too hard to create a script that gets a script from another "source" button and puts it into all the buttons on x cards. Syntax is a bit fuzzy off the top of my head, but something like this: on mouseUp put the script of card button "source" into theSourceScript repeat with bgs = <bg 1> to <bg n> repeat with buttonNo = <button 1> to <button n> put theSourceScript into the script of button buttonNo end repeat end repeat end mouseUp I had this same problem (already with 15 buttons) and did it this way a few months back... -cbb -- Chris Borton borton%uva@mcvax.{nl,bitnet,uucp} Rotary Scholar, University of Amsterdam CS
ns@cat.cmu.edu (Nicholas Spies) (10/01/88)
Actually, you can automate the making of buttons to an even greater extent: you can write a function, which may be passed arguments, to create scripts. Try something of the form... on makeButton cardNum, title, n, m lock screen go card cardNum doMenu "New Button" put the number of card buttons into ncb set name of button ncb to title set script of button ncb to bScript(n,m) -- probably some more stuff choose browse tool end makeButton function bScript n, m -- say n refers to a line in a global variable 'foo' and m is a factor -- that the button will multiply line n of foo by... return "on mouseUp" & return & _ "global foo" & return & _ "put line" && n && "of foo *" && m && "into message" & return & _ "end mouseUp" end bScript The script returned by bScript(10,30) should look like: on mouseUp global foo put line 10 of foo * 30 into message end mouseUp ...its just a matter of concatentating strings. The only potentially confusing thing is that you must insert "return" characters in the middle of the script string with "& return & _" where "_" is the option-return character to prevent lines from running off right end of editing dialog. Remember also that the line continuation cannot be used within a quoted string, only between them. -- Nicholas Spies ns@cat.cmu.edu.arpa Center for Design of Educational Computing Carnegie Mellon University
krona@ttds.UUCP (Kjell Krona) (10/02/88)
One way to accomplish what you want is to use the function
"the target", after giving the buttons in question the name
of the function you want them to execute (for ex, "foo").
Then, in the stack script, place a a handler like
on mousep
if the short name of the target is "foo" then
foo
end if
end mouseup
on foo
-- whatever you would like "foo" to do
end foo
OR PERHAPS
on mouseup
if the short name of the target is "foo" then
put "foo" into bar
do bar
end if
end mouseup
ETC.. (the latter is useful if you would like to have more
than one function, on different buttons)
This can be extended and used with great effect. During the
summer, I have implemented a small object-oriented system with
proper inheritance in this way, complete with a simple Smalltalk-
like editor/compiler. I this system, I also use arguments; the
first word of the button/field specifies the function to execute,
the second word specifies an argument for those functions that
need it. So, differnt buttons may react similarly, but with differnt
end results.
Since "is all in the name" it is quite simple to change the way a
button reacts. Whith the proper scripting done, a user not familiar
with HyperTalk may still change the behavoiur of a button/field,
choosing from the pre-programmed functions avaliable in this way.
i have used this to make a small hypertext application, with the
intention of extending it into a hypertext authoring environment.
In the near future, I also intend to use it as a tool in my research
on what kind of functions should be available i a user-oriented
programmeing environment.
- kjelltaylorj@byuvax.bitnet (10/08/88)
I hope some of you paid close attention to the very good advice Kjell Krona gave in message <1180@ttds.UUCP). He made the very important point that if you have a script that needs to be repeated in a lot of buttons, you don't need to duplicate it for every button. In fact, the buttons DON'T EVEN HAVE TO HAVE SCRIPTS. To reiterate Kjell's message, move the mouseUp handler to the card, background, or even stack script. If you need to differentiate between buttons, use the button name to identify the different classes of buttons, then have your mouseUp handler check the "name of the target" and act accordingly. You can even put "parameters" in the button names. This can make your stacks MUCH smaller and much easier to modify. The cardinal rule of good, structured HyperTalk programming is "If it's duplicated, move it up the heirarchy!" Jim Taylor Microcomputer Support for Curriculum, Brigham Young University BITNET: taylorj@byuvax.bitnet INTERNET: taylorj@yvax.byu.edu