Behavior keeps dying...

Question

I have a behavior on a sprite which seems to do exactly what
it's supposed
to most of the time, but after about 10-20 trial runs in
Authoring mode, it
suddenly just stops responding. To anything. I can even add a
"put"
command into its beginSprite just to see if it's responding,
and it just
doesn't do anything. The only ONLY thing that works once this
happens is to
save, quit, and reload, which is getting really annoying to
have to do every
10 minutes or so. So far it always seems to work in the
Projector, but it's
getting hard to test things on this because of the constant
need to keep
quitting and reloading. There's nothing fancy on this script:
property my
on beginSprite me
my = sprite(me.spriteNum)
end
on mouseUp me
--Set val based on mouse relative position on mouseUp
sprite(my.name.word[1] && "Dropdown Act").val = (the
mouseV - my.top) /
15
--Scroll Activator text to line to match line selected from
Menu
member(my.name.word[1] && "Dropdown Act
Text").scrollTop =
sprite(my.name.word[1] && "Dropdown Act").val * 15
--Menu and Selector disappear on mouseUp
my.visible = FALSE
sprite(my.name.word[1] && "Selector").visible =
FALSE
--Execute command based on val from Activator
case sprite(my.name.word[1] && "Dropdown Act").val
of
0: <do this command>
1: <do another command>
etc. (there's 20 commands total)
end case
end
on mouseLeave me
--Menu and Selector disappear on mouseLeave
my.visible = FALSE
sprite(my.name.word[1] && "Selector").visible =
FALSE
end
on mouseWithin me
--Selector follows mouse on mouseWithin
sprite(my.name.word[1] && "Selector").locV = my.top
+ (((the mouseV -
my.top) / 15)*15)
end
The whole "my.name.word[1]" thing is because I have several
dropdown lists,
each having 3 parts grouped by having similar sprite names.
The "Dropdown
Act" is a 20-line text member fixed-height so that only 1
line shows, which
you click on to activate the menu, it has a property "val"
which is set by
this script. (It has a mouseDown script which just makes the
other two
visible.) The "Selector" is just a rectangle shape with a
Reverse ink to
show which command you have your mouse over. Is there
anything in this
script that stands out as a no-no that would be causing it to
so royally
screw up on such a regular basis?

Answer 1

"Darrel Hoffman" <[email protected]> posted in
macromedia.director.lingo:
> on endSprite me
> sprite(me.spriteNum).visible = TRUE
> end
>
> Does it matter that this happens in another behavior
than the script
> that does the juicy bits?
Nope. That should be just as good, though you might want to
play with the
order of behaviors as attached to the sprite.
Pure guesswork here, but maybe Director still has problems
with .visible if
it's toggled n times in a session?
> As for using the visible property, I know of
> the alternatives, but I don't like 'em. Setting blend to
zero is
> useless, as it doesn't stop script from running on mouse
events. Moving
> them off-stage works, but then you have to put in extra
code to keep
> track of whether it's been moved or not or you end up
moving it
> off-stage twice, or add a property telling it where its
homeLoc is, etc.
> The visible property works on one line of code, and it's
nice and
> simple, provided you remember to make turn visible again
on endSprite.
> (I can't tell you how much I'd pay if the next version
of Director made
> the visible property sprite-specific instead of
channel-specific. If
> they released an 11.5 patch that did just that, I'd buy
it on the spot.)
> Incidentally, I'm still using MX2004, in case that
matters at all.
Yep. I opted for the off-stage method many moons ago.
Slightly more code, but
it's proven reliable for me.
Where to go from here?
Can you observe a pattern occuring when it begins to fail?
ie: certain sprite
channels are visible/not visible?
Perhaps you can create a simple test movie with just your
menu system and
some minimal navigation if that's what your real project
does.
That might help eliminate some possible causes. If it still
happens in the
test movie, see if converting to an off-stage method cures
it.
If not, then I may have led you down the wrong path
altogether and something
else is likely the cause.
If you're open to the off-stage method, I still have my
ancient D7 example
(using graphics for the menus) on my site that you might use
as a quick
starting point:
http://www.mboyd.com/director/windowsui.html
It uses an even
older version of my D7 "MAB beginOffStageGrouped" behavior
shown (perhaps a
bit confusingly) here:
http://www.mboyd.com/director/showhide.html
It's old, but I still use that behavior in every nearly every
Director
project. Not so often for menus, but for artsy dialog boxes
when the client
doesn't want the OS widgets.
(I still get hits on those pages. Maybe it's past time for me
to upload the
D8+ versions of those behaviors.)
For more recent code, I seem to recall seeing some better
written scripts
posted on the DOUG site some years ago. Sorry I don't have
the links avail,
but they should be easy enough to find.
Mark A. Boyd
Keep-On-Learnin' :)