Yes it's true - at some point, it was a challenge for me to swap an image on the stage. Hey, we all start somewhere. About a million challenges later, and voila - a decent Director developer!

Here is how it happened and some of what I've learned: I started using Director a couple of years ago when I was in college in Austria and made my first "baby steps" with it. Granted, I had (little) programming background. I created a very simple application for my niece, which let her solve calculations. Whenever she had one right, she could see a picture of herself. It wasn't anything fancy, but in developing this program, I learned the basics of Director and I gained confidence that I could do more.

After creating a few other small projects with Director, I thought I knew it all and took on a huge job during my internship. The project was called "Virtual Showroom" and the customer was LEGO, an obviously well-known toy manufacturing company.

The task at hand was to transform their paper-based retail catalog into an interactive CD-ROM-based application. The products had to be separated into categories and a menu had to be put in place to access individual categories. Also, we needed to create different product views, a thumbnail view with multiple products on one page, and a detailed product view with bigger images and more information. They also wanted to incorporate their product line video commercials.

Because my knowledge in Director was fairly basic, we had to create every page "by hand." We took a product image, made it the correct size for both thumbnail and detailed views (we used PCT images, because this format allows for gradient alpha channels), and placed it on the Director stage. Now, multiply that by about 200 products. This doesn't seem so bad, right? Well, it soon turned out that this method wasn't very effective because product lines, images, and info constantly changed during the development process. Proofing was a nightmare. For the next version, we needed to create something more updateable and dynamic.

We are into version 5 of this project right now and it's fully updateable. It also includes product-ordering functionality, database access to client data, PowerPoint marketing presentations, videos, and lots more. I can't go into much detail about how we pulled it off, but I'll try to give you some ideas.

The heart of the program is a big list of property lists containing all of the product info. This list is dynamically generated on startup of the "Virtual Showroom" from a tab-delimited text file. As you may know, a file like this can be exported from many database-like applications, including Microsoft Excel. We chose to go with this format because the requirements for knowledge and software of the person editing the data are few. Another advantage is that products come up in the exact order in which they are listed in the Excel file, so no numbering is needed. I have to say that this list is HUGE, but it does not bog down Director at all. Even working through the entire list to calculate totals only takes a split second.

This is a simplified version of what the list looks like:

dbList = [[#name: "product1", #price: 12.00], [#name: "product2", #price: 40.00]]

In order to access the price of product 2, I simply call this command:

Price = dbList [2].price

On to more secrets - how we are dealing with product images. Every thumbnail and detailed product view is generated dynamically. All images are available in an external cast. Using "Standard Import" when importing all images into this cast would have made the cast file size too big, so I only linked to the images. Even when linking to the images, the cast was somewhat big, because Director automatically creates thumbnail images for each imported image. To work around this problem, I wrote a routine that replaces the thumbnail image for each cast member with an image of one pixel black.

member(memberNum, imageCastNum).thumbnail = member("thumbnail").picture

The cast contains 800 linked images and is only about 500 kb!

For the dynamic product-page generation, I created template screens with transparent placeholder sprites for product images. Depending on the viewed product, I swapped out the placeholders with the actual product image from the image cast.

There's one last thing I want to mention here because it is a trick I've used over and over again, even for other projects. If you want to create an overlaying menu, video interface, or whatever, without using MIAW, you can try this:

Consider the fact that I have a project with some sort of content on the stage and a button that, when clicked, is supposed to display an overlaying menu. First, I create a button behavior for the menu button that takes a screenshot of the stage and goes to the "menu" frame.

on mouseUp me

member ("screenshot").image = (the stage).image
go "menu"

end

The member "screenshot" can be any bitmap cast member. I would just import any image and name the member "screenshot." Of course, now I have to create a "menu" marker and put the "screenshot" member in the center of the stage. Create an exitFrame behavior so the playhead stays on the menu marker once it gets there. Try this and see what happens. You will see that there is a seamless transition from the actual content to the "menu" frame with the screenshot. Now you can go on to create whatever menu you would like on the "menu" frame. I hope the benefits of this process are clear: it certainly cleans up the timeline and simplifies the task of creating anything that needs to overlay the stage.

Obviously, there's a lot that I can't explain here. To make a long story short - I sweat, I swore, and I conquered.

Troubleshooting
Being able to troubleshoot is almost as important as being able to program with Director. It just so happens that there are ALWAYS last-minute problems with a project, and this is a rule with few exceptions.

As frustrating as it can be to troubleshoot, the bright side is that you'll learn a lot in trying to figure out the problem. And if everything you try fails, there's always Macromedia Tech Support to help out. Anyway, here are some tips I can give after endless hours of troubleshooting.

Prepare Your Troubleshooting
There are a lot of ways to get to the bottom of a problem. However, making troubleshooting easier, because you know it's coming, can start at the beginning of a project.

Externalize Scripts
Whenever I start a project, one of the first things I do is create an external cast that is called "scripts.cst." Needless to say, all of my scripts are placed in this cast. Doing this brings a lot of advantages: Apart from being able to reuse scripts throughout the entire project, changes can be made very efficiently. It also saves time, because you don't need to create a projector every time you make a change to your scripts. Also, if a customer calls with a problem, you can update your scripts cast and e-mail it to your customer (because there are only scripts in this cast it's also very small). The customer can then replace the file on his end and see the changes instantaneously.

It's also a good idea to create a stub projector. To do that, I create an empty director file and a "startMovie" script. The startMovie script looks like this:

On startMovie
initProject ()
end

I declare the initProject method on a script sheet in my external scripts cast. In this script, I initialize all necessary variables and tell the projector to go to the first movie. That way, I have all scripts "external" and I have control over almost everything without creating a new projector.

Display Full Error Text
Another preparation I make at the beginning of a project is to create an ".ini" file, which is called the same name as the projector. For example, if the project is called "test.exe" I would have a file called "test.ini" containing the following text:

[lingo]
DisplayFullLingoErrorText=1

This file ensures that the full error text is displayed when a script error occurs while running the projector. Instead of just saying "Script error" when there's a problem, the message will give you more detailed information as to why it occurred, as you would see in the authoring environment. I find this to be very helpful.

Verify Xtra Versions
The last thing I want to mention here is about Xtras. Make sure all Xtras are the correct version for the given Director version. If this isn't the case, it can create all sorts of bad (but sometimes subtle) problems. A typical case of this would be when everything seems to work fine in the authoring environment, but not when you run the projector.

What to Do When a Customer Calls With a Problem
Just when you think you're done with a project, there are those painful calls - the customer says that this or that isn't working, the project crashes, it doesn't run smoothly enough - and YOU have to take care of it FAST. Here is how you prepare your troubleshooting process:

Get All the Info You Can Get
It's very important that the customer helps you in trying to narrow down the scenario that is creating the problem. If you know that the problem always occurs when you hit a specific button, you're already halfway there. Have him/her send screenshots of any error messages (this is where the previously mentioned .ini file comes into play!).

Before you start going crazy trying to figure out the problem, make sure that the customer is running the project on an "allowed" system. Also, have him/her explain exactly which actions were taken before the problem occurred. For example, "First, I clicked on a product, then I opened the menu, etc.," just make sure he or she isn't trying to do something he or she isn't supposed to be doing. For example, I had case where the customer was trying to run two instances of the projector at the same time, which would obviously create problems. If you think the problem might be due to a corrupt file, send another copy, or e-mail/FTP the file in question for the customer to download.

Verify the Problem
Once you have as much info as you can get, the challenge can begin. The first step you should take is to verify the problem on your end. If you have a system setup that's similar to your client's system, you should be able to recreate the problem. This will speed up the troubleshooting process tremendously because you'll need less input from your client in testing the possible solutions.

Use Your Resources
The second step I usually take is searching the Tech Support section on www.macromedia.com as well as their user forum. I have found answers and work-arounds for so many problems there because chances are, if you're having this problem, someone else had it before you and found a solution for it - don't re-invent the wheel, it just doesn't pay very well. Some people on these forums seem to know it all "Mark A. Boyed," whoever he is, must have posted thousands of answers. I want to thank everybody on the user forum for their valuable input to the Director community and for saving my a** over and over again.

Troubleshooting Methods
Whether or not you found answers, it's time to get your hands dirty. First thing: MAKE A BACKUP OF YOUR EXISTING VERSION and take the "Final" label off this one!! I didn't always do this, and sometimes I really regret it.

Be Creative!
If you found answers anywhere, implement and test them. If you didn't find answers anywhere, there are some things you can do before calling Tech Support. One very good trick I discovered recently is putting the following command in your "startMovie" or "initProject" script:

the debugPlaybackEnabled

This command brings up a message window during runtime and you can use it just like the one in the authoring environment. This is a tremendous help when problems only occur in projector mode or on certain operating systems. Even still, you'll have to be creative in finding the bug! Anything is possible - I have experienced the oddest and most unusual problems. A command line that doesn't create problems in one spot could create problems in another for no obvious reason. Pay attention to memory usage in the task manager! Sometimes a problem causes the projector to keep eating up memory and never clear it out again, even when using unload commands. Certain script sheets can become corrupted, so copying and pasting the script into a new script sheet and deleting the old one may help - like I said, anything is possible.

Top-Down Method
I usually start solving problems this way. What I mean by "top-down" is that you start taking stuff (script lines, images, etc.) out of the project and keep testing, testing, testing, until you don't experience the problem anymore. Of course, it's important to keep track of your changes. Whatever you changed last before the project started working again is probably the root of the evil. If you can't take anything out, I would try finding different ways of implementing the particular parts of your project that seem to cause the problem. For instance, using an Xtra instead of built-in Director commands may help. Or maybe if using MIAW seems to be a problem, you can avoid using it using the "screenshot" method I described earlier.

Bottom-Up Method
Once you have an idea of what the problem is, it's often good to start with a blank project and recreate the problem on purpose with the simplest assets possible. At least you will verify that what you found out is true, and you can also start working on a work-around in a test bed instead of pulling apart the real project. Remember, work-arounds don't have to be elegant - as long as they work.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5