Director FAQ || Notes ~ Short Index ~ Full Index ~ Search || Prev ~ Next ||

[18] Shared.Dir Issues

• 18.1 What is a SHARED.DIR?
• 18.2 Why would I want to use a SHARED.DIR?
• 18.3 How do I create and use a SHARED.DIR?
• 18.4 What are some gotchas or characterstics of using a SHARED.DIR?
• 18.5 Can I have multiple SHARED.DIRs?
• 18.6 Does the SHARED.DIR work under Mac and Windows?
• 18.7 Can I put xobj/font/cursor etc. resources into a SHARED.DIR?

NOTE: This is only useful if you have several linked Director files which share similar attributes (eg code, picts, sounds), and not if you plan on putting everything into ONE large Director movie file.

First, you can save lots and lots of space. For instance, you may have 9 linked Director files which all use the same 640x480 background. Rather than put this background in all 9 movie files; 9*300k = 2.7 MB, (assuming the PICT is 8-bit), stick it once in your SHARED.DIR; 1*300k + 9 references to that pict = 301k-ish; and you can see how much space you've saved already (for the mathematically impaired, that around 2.4 MB). With the slowness of CD-ROMs, this difference is even more pronounced. Everything you can do to minimize the size of your file is critical. For instance, by creating a SHARED.DIR for a project I was working where I had 30 files that were around 400K each, I created a SHARED.DIR (onetime size of around 1.6 mb) and each of my other files were between 48 and 60k. Quite a difference in speed when loading each file and I ended up with a much smaller total overall project size.

Second, suppose you have certain scripts (for instance "go to the frame", "pause", button handlers, etc.) which you use over and over in your other movie files. Why create these scripts individually for each file when you can simply create them once? (fewer total scripts = faster playing) Even though you may be copying and pasting these scripts over and over again into different movies, it's still more efficient to use a SHARED.DIR because you create them ONCE and then they are available instantly in EVERY movie file you have. An additional advantage of this, is the code is more object-oriented (without even having to learn parent-child scripting! :) ).; Let's say that you have a particular handler you use for every button you've created, and that you have 9 movie files which have this button in them. With a SHARED.DIR, if you need to change the properties of that button, all you do is open your SHARED.DIR , modify the handler, and it is instantly updated throughout all 9 movies, ready to use. If you just copied and pasted the script without using a SHARED.DIR, you still gotta go through all 9 movies (one at a time) and find the handler, and change it, save the file, move the next one, repeat...

1. You cannot move SHARED.DIR castmembers around unless you are currently in the SHARED.DIR file. You can, however, cut and paste them to a different cast location. (but then you have to make sure you haven't referenced the old cast location in the score, because it will not update automatically)

2. You can have only ONE SHARED.DIR officially, but there is a way around this. (see [18.5])

3. Anytime something in the SHARED.DIR is moved, and you open one of your other movie files, Director presents you with a dialog box which asks you if you want to update the file to reflect the changes. This is helpful because it also tells how many items were moved.

4. You can copy and paste cells from the score from one movie file to another, and if the items you have selected are from the SHARED.DIR, Director is intelligent enough not to paste them into the new file when you paste the cells, it simply references the SHARED.DIR cast. This is VERY handy. On the same token, if you copy a cell that contains, let's say, a PICT which is not located in the SHARED.DIR, it will be copied into your new file when you paste the cells. In other words, watch your cast carefully even if you *think* you're pasting only cells which contain SHARED.DIR elements.

5. The "Switch castmembers" command (command-E) is quite useful for replacing old castmembers in your file with ones located in the SHARED.DIR.

6. The SHARED.DIR is NOT a good place to put "on startMovie" or "on endMovie" handlers, because these are typically set up differently for each Director file and you don't want to start having conflicts with your "startMovie" handlers within each movie and the SHARED.DIR. Even if you plan on doing the same initialization in each Director file, I've found its better to simply call a handler you've created, and not the built-in "startMovie" and "stopMovie" handlers. This insures that you don't "accidently" create a "startMovie" handler in both places. This is especially easy to do, because Director will only find castmembers "not used in the score" if you do a "find castmembers" and will not highlght movie castmember scripts or SHARED.DIR castmembers. Therefore you won't catch your duplicates by doing a "find all castmembers which are not used in the score."

I've been told by Macromedia, and others, that it is not possible to switch the SHARED.DIR file on the fly using Lingo. This is just not so.

My solution for the changing of the SHARED.DIR is simple. It involves using many small SHARED.DIRs to compile a larger one. This works well from the kiosk side. I'm not sure if it has the same value from the CD perspective. Of course, this also allows for straight swapping of the SHARED.DIR file.

Using different folders for each shared movie, the main movie (hence called "main") will use the command:

   play movie (the pathname:foldername:newsharedfile)

Upon playing this movie it executes a frame 1 script or on startMovie handler:

   savemovie "the original pathname:shared.dir"

NOTE...this script must be stored in a cast number greater than the start of the shared file or bad things will happen.

This effectively overwrites the original shared file changing it for all other files to use. A "play done" returns to the original movie with the new shared movie ready for consumption.

Normally if you try to overwrite a SHARED.DIR you will get a nasty disk error message, because it is in use. However, because the new shared file is in its own folder and therefore does not see the original SHARED.DIR file, overwriting is a snap.

Now, this method can be used for simply swapping SHARED.DIRs or can be used in conjunction with the "duplicate cast" command to actually build the original movie from scratch. (that is what i use it for).

With the poor FileIO performance of director, first reading, analyzing, and then importing graphics, this new SHARED.DIR method is actually much faster. Besides, I was told that it couldn't be done. That's enough to make me want to do it.

URL: http://www.mcli.dist.maricopa.edu/director/faq/faq18.html