*** This is part two of a two-part reply ***
Genevieve Young <[EMAIL PROTECTED]> wrote:
> tPropertyList[ \
> #OriginalMember] = [ \
> #comment: "Original member:", \
> #format: #bitmap, \
> #default: #void \ -- 6. can a bitmap be considered void? How would I know?
> What are the defaults? Can anything be void? Error is here: comma
> expected? Why do I need a comma here?
> ]
You can't add comments in this way. Try like this:
tPropertyList[ \
#OriginalMember] = [ \
#comment: "Original member:", \
#format: #bitmap, \
#default: #void \
]
-- 6. can a bitmap be considered void? How would I know?
-- What are the defaults? Can anything be void? Error is here:
-- comma expected? Why do I need a comma here?
Director says it expects a comma because it doesn't know how to handle a
comment inside a list, and it doesn't know how to tell you this.
To answer your question about void: #void is not void, it is a symbol. Try
this:
put void
-- <Void>
put ilk(void)
-- #void
The list returned by the getPropertyDescriptionList() handler must include a
default value. However, the default value may be inappropriate. In this
case it will be replaced by the first value in the #range list. You do not
explicitly provide a #range list. By choosing #bitmap as the format, you
implicitly tell Director to create a list of all bitmap members. You should
see these displayed in a popup menu.
If your movie contains no bitmap members, Director tries its best to
understand what you want. It will adapt the format to correspond to the
default value you provide, and show a text input field so that you can
change its value. You might end up with something like this:
put sprite(1).scriptList
-- [[(member 1 of castLib 1), "[#OriginalMember: #text_entered]"]]
When you run your movie, Director will show a script error, since it can't
set the member of a sprite to a symbol. Your best bet is to provide a
default value that is of the same ilk as the value you expect. Though you
can't tell in advance where the first bitmap member in your cast will be,
you can force Director to use a member (which may not be a bitmap):
tPropertyList[ \
#OriginalMember] = [ \
#comment: "Original member:", \
#format: #bitmap, \
#default: member 1 \
]
Even better, if the isOKToAttach() handler limits you to dropping this
behavior on a bitmap member, you can use the current member of the sprite as
the default. Since this will automatically be the "Original member" of the
sprite, you kill two birds with one stone:
on getPropertyDescriptionList(me)
tPropertyList = [:]
if the currentSpriteNum then
tDefaultMember = sprite(the currentSpriteNum).member
else
tDefaultMember = member 1
end if
tPropertyList[ \
#OriginalMember] = [ \
#comment: "Original member:", \
#format: #bitmap, \
#default: tDefaultMember \
]
-- etc.
Note that I test whether the currentSpriteNum is not void, and I provide a
different default value if it is. This is because Director also calls the
getPropertyDescriptionList() handler when it recompiles the behavior script.
It does this to check if the property list has changed, so that it can warn
you that the properties and values you previously used may now be invalid.
When it does this, the currentSpriteNum is void, because Director is
concerned simply with the script and not with any sprites the behavior
script may be attached to.
> tPropertyList [ \
> #pActionSound] = [ \
> #[comment: " Action Sound ", \
> #format: #sound , \
> #default: * *] -- 7. why is the default * *?
This causes a script error. Since Director already reported an earlier
script error, you might not have been alerted about this one yet. Again,
your safest bet is to use "member 1" here, as you are looking for a sound
member. I would imagine that Gary intended you to fill in the gap here.
> if pActionLingo <> ** then -- 8. what is the meaning of this?
> ----why do I specify it?
> do pActionLingo
> end if
> end
Again, it looks like Gary is expecting you to fill in something here. I
don't have a copy of the book to hand, but I would be tempted to change this
to:
if pActionLingo <> "" then
do pActionLingo
end if
The reason for this is that do "" will simply take up time, but nothing will
happen.
> -- 9. why is the �doAction� used on page 296? It can figure out navigation
> and sound? Is it something similar to �ActionLingo�?
> Have I made a mistake here by using it?
Have a look at the "do" command in the Lingo Dictionary. Gary's idea
appears to be to allow you to execute some arbitrary command on mouseUp.
You might like to try entering one of the following strings in the Parameter
dialog:
set the stagecolor to random(255)
beep
alert "You just clicked me"
Here's a minimalist behavior that uses "do":
on getPropertyDescriptionList(me)
tPropertyList = [:]
tPropertyList[ \
#action] = [ \
#comment: "Action:", \
#format: #string, \
#default: "beep" \
]
return tPropertyList
end
on mouseUp(me)
do me.action
end
Cheers,
James
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
