Prev: External source editor
Next: Problem in minimizing the MIAW
From: kindaian on 5 May 2008 05:10
That is something that depends ALOT on what you are doing and how you do the
whole development.

I'm from a more "structured" programming environment and find it funny how
Director manages the "programming" in it.

My development efforts in D11 will make me do the following structure for ALL
scripts:

1. All will be external linked.
2. Scripts will be either generic lib stuff, generic behaviors or specific
stuff. All lib will be on a file called "lib.ls" all generic behavior will be
in external files with their names terminated with ".ls". And the specific
stuff will be with a file "cast_object_event.ls".
3. All scripts are stored in version control (subversion in my case) and
placed all on the same directory inside the main project directory.

Now i only wished that D11 had subversion support (because there is no way i
will be using the non-standard version control system proposed by Adobe).

Cheers,
Kindaian

From: Darrel Hoffman on 5 May 2008 09:06
> 1. All will be external linked.
> 2. Scripts will be either generic lib stuff, generic behaviors or specific
> stuff. All lib will be on a file called "lib.ls" all generic behavior will
> be
> in external files with their names terminated with ".ls". And the specific
> stuff will be with a file "cast_object_event.ls".
> 3. All scripts are stored in version control (subversion in my case) and
> placed all on the same directory inside the main project directory.

Is any of that stuff possible in MX04? I'm waiting on D11 until the first
couple rounds of patches come out, I've heard some horror stories. I mean,
I know I can make an external cast, and put all the scripts into it, but I
don't know how much benefit that would be at this point, unless maybe I were
sharing scripts between multiple .dir files, which I'm not (yet, though
maybe soon).


From: Mike Blaustein on 5 May 2008 09:35
I don't think he means external castlibs. He means that the actual
scripts are external files. You can do this in the PI on the Script
tab... there is a 'Link As' button to make the script actually be an
external text file. You can then edit the script in other programs
apart from the built in script editor (which has serious speed issues on
D11). Being able to use Subversion with the scripts is a nice thing.
I've been meaning to check it out some day...

As far as my organization goes, I would call it "chaos". Actually, I am
pathological about naming all of my script members, and my handlers all
have well-thought-out names so I generally know what I am looking for
and find the appropriate member by name... then drill down to the
handler. All my scripts are usually in a single cast, but sometimes I
put related elements into their own casts... if a program has 3 parts, I
may use 3 castlibs with the members/scripts separated out like that.
Depends on the project really.
From: Darrel Hoffman on 5 May 2008 11:14
> As far as my organization goes, I would call it "chaos". Actually, I am
> pathological about naming all of my script members, and my handlers all
> have well-thought-out names so I generally know what I am looking for and
> find the appropriate member by name... then drill down to the handler.
> All my scripts are usually in a single cast, but sometimes I put related
> elements into their own casts... if a program has 3 parts, I may use 3
> castlibs with the members/scripts separated out like that. Depends on the
> project really.

My method is pretty similar - I do name all the script members, and give the
handlers good names, but there's just so many of them now it's getting hard
to find them. If the dropdown from the script window could be set to be
sorted alphabetically or something, it'd be MUCH easier. The other annoying
thing is if a sprite has multiple behaviors on it, you can't just
right-click it click on the "Script" in the menu and necessarily get the
script you want. I've found that generic scripts like

on beginSprite me
sprite(me.spriteNum).visible = TRUE
end

need to be located lower down in the Cast in order to make them not be the
default that comes up. In other words, it doesn't matter what order the
behaviors are in on the sprite, the only thing that matters is what order
they're in in the CAST, which really makes no sense. The one on top of the
Behavior list should be the default, I think. Or maybe the one on the
bottom, I don't know, but one way or another, the order of behaviors should
be taken into account, and it isn't. Only their member numbers. Also I
find it really annoying that if a sprite is located underneath another
sprite that's locked, right-clicking on the sprite doesn't work, because the
locked sprite intercepts it, so you either have to click the sprite, then
CTRL-SHIFT-QUOTE to get the script (which again picks the first one in the
cast, not always what you want), or go up to the Behavior Inspector and
manually choose the one you want, or find the thing in the Score instead.
Any of these methods takes far longer than it rightly should compared to a
nice right-click context menu. I'd just like it if there were some nice and
convenient way to find things in your scripts, but unfortunately, it can get
to be a real bear the more complex your project gets.


From: Mark A. Boyd on 5 May 2008 18:50
"Darrel Hoffman" <no.address(a)all.com> posted in macromedia.director.lingo:

> All
> I get are the names of the script members, without any easy way to jump to
> the exact handler I'm looking for

Not sure if this helps, but you can do a Find Handler by using
[Ctrl]+[Shift]+; which allows you to sort by Name.

I keep an external castLib with scripts that are likely to be used in all
movies. I keep another external castLib with common controls, such as video
controls which includes both the graphics and the scripts related to them. If
a project or movie does not use video, I don't attach that castLib.

In movies with scripts specific only to that movie, I will /normally/ place
the script members in the first slots of the internal castLib. Once in a
while, I will create a separate internal castLib to contain these scripts.

One thing I found that helps in the drop-down menu is naming the first and
last script members in a castLib a little differently. For instance, my 'go
the frame' behavior used in all movies resides in member 1 of the external
scripts castLib. The script member is named something like '----- begin
Common Library -----'. The last script member in the castLib is named
something like '----- end Common Library -----'. I generally only do that for
castLibs containing only scripts, but it does help.


--
Mark A. Boyd
Keep-On-Learnin' :)
 | 
Pages: 1
Prev: External source editor
Next: Problem in minimizing the MIAW