Associated Email list Windows_For_Shockwave

Current Version
WFS48p3 (Professional)
WFS48s3 (Standard)
(email me for free updates through version 4.x)
What's new in WFS48

This Document
What is Windows For Shockwave?

Dynamic Sprite Creation
Buy, Download and Install WFS
System Requirements
What's New in Version 4.8
To Users of Previous Versions
Example Movies
Learning Windows For Shockwave
Role of WFS in Your Applications


Site Nav

css drop down menu by









Optional script that supports dynamic sprite creation and destruction. Mandatory for every project that uses WFS. If you use the 'Drag Element' behavior, you need a copy of the 'Drag Element b' script in a cast. Attach this to elements you want to drag. Configurable to define a constraint area of motion. Each WFS window has one of these bimaps in it. Each WFS window is managed by a  Window Manager. Each element of each window and menu must have a copy of this attached to it. Turns an element into a control that closes the window it's part of. Turns an element into a control to drag a window or menu. You need this in a cast if you use the '6: Handle' behavior Turns a sprite into a control to open a window Turns a sprite into a control to close a window. Lets you choose the cursor image for each mouse event. All internal cursor images are available. Turns a sprite into a rollover control that opens/closes a window. Every menu has a copy of this bitmap in it. Every menu is managed by a different copy of this behavior. Each menu item has a copy of this behavior attached to it. This vector image is used to highlight menu items. This behavior works with the 'Menu item highlight vector' image This solely decorative vector image is used in menus, if you like. This optional movie script contains handlers that you aim at elements or multi-sprites or families thereof. It writes handlers for you that create dynamic elements, multi-sprites, or families thereof.

WFS 4.0a as it appears in the
Director Library Palette


Go to top of doc. Windows For Shockwave (WFS) 4.8

What it is

Windows For Shockwave is a set of Library Palette behaviors for Director 8.5+ (not an Xtra) that enables

  • drag and drop creation of onstage windows,
  • modal dialog boxes,
  • cascading menus,
  • right-click (Control+click in Mac) pop-up menus,
  • and good cursor image control.
  • More generally, the main idea of WFS is the 'multi-sprite', sort of like LDM or Movie Clips in Flash: you create multiple sprites that are treated as a unit, and the WFS behavior library and API supply you with ways of operating on elements of multi-sprites, multi-sprites, and families of multi-sprites. There are two types of multi-sprites in WFS: windows and menus.
  • WFS also supports creation and destruction of dynamic sprites,dynamic windows, dynamic menus, and dynamic families thereof.

WFS can be used in the creation of Shockwave movies or Projectors. The drag and drop behaviors are suitable for Director developers with no Lingo knowledge. WFS also supplies an extensive API for programmers to access more functionality.

WFS eliminates the need for dummy sprites through its optional dynamic sprite creation feature. And the WFS "Script Writer" handlers write the Lingo for you. Create windows and menus in an easy drag and drop way. Then aim the "Script Writer" handlers at the static model and WFS creates handlers that, when called, create dynamic copies of the static model.

The level of Lingo knowledge required to use the WFS dynamic sprite features is less than intermediate, whereas dynamic sprite creation/destruction/management is an advanced procedure with gotchas without WFS; WFS is the only system that lets you manage dynamic sprites. And WFS is the only system for creating windowed applications for Shockwave.

Some developers use WFS as an alternative to MIAW in making projectors. Others use WFS to create windows and menus in Shockwave. Others use it as an alternative to LDM (Director's buggy version of the Movie Clip concept). Others use WFS as their windowing and menu-making tool whether they are developing projectors or Shockwave.

Check it out

Chuck Neal of reviewed WFS 3.0. Also, read an overview of WFS 3.0 (that includes six DCRs) for an overview of the 3.0 features. There's an overview of the dynamic sprite creation/destruction capabilities of WFS 4. The WFS 3 and 4 overviews are published on Thanks to Darrell Plant and Gary Rosenzweig for editorial assistance.

Behaviors + Examples

You can use the bitmaps and vector graphics included with WFS, in the library and in the tutorials, to create your own windows and menus, or you can use your own graphics. Usually in application development environments, the look of windows and menus is prescribed. Not so in WFS, though they can be standard looking, if you want. WFS primarily supplies you with behaviors, not graphics, though the examples are often fairly slinky, as windows and menus go.

Low Computational Overhead

The computational overhead of WFS is very low. The only scripts with frame event handlers in them are the "6b: Handle" and "Drag Element b" parent scripts. Each of these only does one comparison per frame of constant processing. Also, those two parent scripts are in WFS so that no matter how many instances of the "6: Handle" and "Drag Element" you use, WFS only does, at most, 2 comparisons per frame of background processing. So you can use WFS without worrying about it slowing your app down. WFS is built for ease of use and strong performance. And everything is well-documented both above and below the hood.

Dynamic Sprite Creation is Unsupported by Macromedia

WFS Standard does not use 'dynamic sprite creation/destruction at all, but WFS Professional includes the "Script Writer" and "Dynamism" scripts that let you optionally create and destroy dynamic sprites.

"Dynamic sprite creation/destruction" is accomplished via puppeting and unpuppeting empty sprite channels in Director 8.5 and less. Experienced developers have been doing this successfully since Director 5, but it is unsupported by Macromedia. In other words, they do not guarantee that this functionality will continue to work properly in subsequent versions of Director. They do not do thorough testing of the associated features in making new versions of Director.

WFS uses the new makeScriptedSprite and removeScriptedSprite commands introduced in DMX 2004. WFS checks to see which version of Director you're using. If you're using DMX 2004 or higher, it uses makeScriptedSprite/removeScriptedSprite; if you're using an earlier version of Director, it uses puppetSprite. The makeScriptedSprite/removeScriptedSprite commands are apparently the start of a migration to officially support dynamic sprite creation, but it is important to note that it is still, nonetheless, unsupported. The makeScriptedSprite/removeScriptedSprite commands use the same old puppetSprite implementation under the hood, at the moment.

Check out the WFS email list for more info on makeScriptedSprite/RemoveScriptedSprite, and check out the primary WFS documentation for info on how dynamism works in WFS.

You do take a chance in using dynamic sprite creation/destruction in WFS Professional. Use it only if your project leaves you with no other choice.

Purchase, Download, and Install WFS 4.8

Click to purchase and download WFS 4.8

Go to top of doc. System Requirements

Macromedia Director 8.5+ (Mac or PC)

Go to top of doc. What's New in Version 4.0 and 4.8

  • See the update page for info on what is new in 4.8. Below is what's new in 4.0.
  • Easy to use Dynamic creation/destruction of elements/multi-sprites/families of multi-sprites. No more allocation of dummy resources in Director. This makes for faster apps and you can have more sprites of any particular resource-type than you can when you have to load the Score with n dummies. See scenes 10 and 11 of the feature tour.
  • Still works like 3.0 except for the added dynamic creation/destruction functionality, so if you know 3.0, you'll find 4.x a snap.
  • Elements can now be named via the "4: Window/Menu Element" behavior and an API exists to retrieve spritenums of named elements.
  • New "Drag Element" behavior that constrains elements to their window or a configurable rectangle relative to the element's window. See scene 13 of the feature tour.
  • Enhanced API for parent-child support and improved wfsSetParent and wfsSetChild. You can see the new features in action in scene 9 of the feature-tour.
  • Enhanced "6: Handle" functionality so that multi-sprites can be constrained to move within some other multi-sprite (or the stage or their parent) and the "6: Handle" behavior does less computation. One or a hundred instances of the behavior do the same amount of constant computation: at most 1 comparison per frame of constant processing. See scene 12 of the feature tour.
  • Expanded Window Manager Parameter Dialog Box to permit initial centering of window and control over whether children stay in front of parents.
  • Expanded API in several behaviors and scripts.
  • Smarter multi-sprites. Elements can come into existence after the multi-sprite has been moved by the user but still the elements assume their correct position within the window (or menu). See scene 3 of the feature tour.
  • Many bug-fixes.
  • New tutorials with audio and animated instruction (tutorial 1 and tutorial 2) . Each of these has more than a half-hour of instruction in how to use WFS. These make getting started with WFS much quicker than normal tutorials. The tutorials are highly navigable, also, so you can reference them and find things within them easily. There are 8 tutorials in total (see the menu at top left of this page). All of them are new to WFS 4. Two new tutorials ( 9 and 10 on the Dynamism API).
  • Indexed documentation search engine (Search Maker Pro) and updated documentation
  • All WFS globals are named so that now they begin with "gWFS"; all WFS properties now begin with "pWFS"; all WFS handlers now begin with "wfs". So you are guaranteed to have no name-space conflicts with WFS globals, properties, and handlers as long as you don't begin your globals with "gWFS" nor your properties with "pWFS" nor your handlers with "wfs".
  • Version 4.8 was developed in Director MX 2004 on Windows XP.

Go to top of doc. To Users of Previous Versions

If you are upgrading old projects that use WFS version 3, you should delete all the version 3 behaviors and other WFS media elements and reattach version 4 behaviors. Do not mix version 3 and version 4 WFS behaviors. All WFS globals, since 4.0, are now named so that they begin with "gWFS"; all WFS properties now begin with "pWFS"; all WFS handlers now begin with "wfs". So you are guaranteed to have no name-space conflicts with WFS globals, properties, and handlers as long as you don't begin your globals with "gWFS" nor your properties with "pWFS" nor your handlers with "wfs".

If you are upgrading from version 4.x, then follow the below instructions:

  • Copy the new .cst file to the Libs folder of your Director installation. You may wish to delete the old .cst file.
  • Open Director and your project .DIR file
  • Create a temporary new cast.
  • Drag the WFS scripts and media elements in the Library Palette into the temporary cast.
  • Click on a WFS icon in the temporary cast.
  • Edit>Copy Cast Member to copy the member.
  • Click on the corresponding icon in your cast.
  • Edit>Paste to paste the member over the old version.
  • Do that for each of the WFS icons.
  • Delete the temporary cast.
  • To initialize all the "4: Window/Menu Element" behaviors properly, select all sprites that have the "4: Window/Menu Element" behavior attached to them. Go to the Behavior tab of the Property Inspector and open the Parameter Dialog box. Check the first box and make sure the second box is blank. Click OK.
  • The only way the API has changed in 4.x is the wfsCreateWindowManager parameters. Note that it now has an additional parameter: centerWindow. And it is the third parameter. So if you have called this handler yourself somewhere in your code, search your code for "wfsCreateWindowManager" and insert a boolean as the third parameter, which says whether the window to is to be initially centered or not. If you haven't used this handler in your code, you don't need to do anything about it.

Go to top of doc. Example Movies

  • The feature tour is the main illustration of WFS features. WFS comes with the DIR to the feature tour. This is the DIR I used to develop WFS.
  • The menu at top left is built with WFS.
  • The menu in Paris Connection.
  • Tutorials 9 and 10 contain Shockwave pieces that illustrate how to code dynamic sprites.

Go to top of doc. How to learn Windows For Shockwave

The documentation consists of four types:

  • Tutorials. The first two tutorials (see the menu at top left of this page) include audio and animation set within a simulation of the Director authoring environment.
  • The .dir files on which the tutorials are based (which are included in the download) are in the 'samples' folder of the documentation.
  • Documentation concerning the use of each behavior, bitmap, and vector (see the menu at top left; it links to all the documentation).
  • The code of the behaviors themselves is extensively documented for Lingo programmers.

Learn how to use WFS like this:

  1. Go through the tutorials (look in the documentation menu at top of page on left). That will give you the big picture plus many details.
  2. Then peruse the documentation concerning each behavior and other WFS elements.
  3. If you are a Lingo programmer, you will want to have a look at the API available, and will also want to peruse the code of the behaviors themselves.
  4. You may also want to subscribe to the email list devoted to Windows For Shockwave. I (or others on the list) will try to answer all questions that come from subscribers to the list. But please consult the documentation before asking questions.

Go to top of doc. The Role of WFS In Your Applications

Suggestion: Structure your app with windows

I suggest that you consider making everything you create in your projects part of some window. It is not a requirement when you use WFS, but you may find it helpful. There is no drawback to this because the computational overhead of WFS is very low; the only constant execution WFS does is when you make a window draggable by dropping the "6: Handle" or "Drag Element" behaviors on sprites, and even these behaviors do only one comparison per frame if the window or an element is not being dragged.

The benefit of doing this is that you can construct applications in your movies much easier. Why? Because you can have multiple windows onstage at once without having to sweat. And cascading menus. Or multiple cascading menus. And right-click pop up windows without sweating. And modal dialog boxes. Windowing is much easier. You easily make groups of sprites appear and disappear while not changing other groups. You easily transfer sprites between groups. You easily center groups or otherwise move the group as a unit. And in 4.0, you easily create and destroy groups while staying in the same frame or general area of the Score.

Note that these sorts of entities are supported very well in C++, Delphi, Visual Basic, etc. Why? Because they are the basic building blocks of applications! Why? Well, multiple windows in applications are usually associated with the ability to create several documents simultaneously. In Photoshop, you can have many documents (pictures) open at once. Same with Word and most other apps which are tools for making some file type or types. And you usually have an extensive cascading menu because that's where your tools are for operating on the documents you create. And you generally can open multiple dialog boxes from the menus because that's where you configure your tools.

Windowing is typically how groups of entities are collected and operated on as a unit. Whether we're talking about Photoshop and its windows or a game in which the underlying structure is not so much two teams against one another as it involves all the support staff and the groups they fall into. There are individuals on the field and behind the scenes but most of them are part of some group that functions as a unit. Windowing is the natural way of arranging visible groups of sprites into coordinated units. WFS windows do not have to look like typical windows. Think of them as coordinated groups of sprites.

WFS in and out of Context(Art)

I made WFS so I could create the sort of art I want to create. Which is software art. And the application is important to software art. But obviously the application is important outside of art also. WFS will be useful to artists and professional business application developers alike.

Go to top of doc.



apis.htm arrowformenus.htm closeawindow.htm closemywindow.htm credits.htm cursorcontrol.htm dragelement.htm dragelementb.htm dynamism.htm dynamismattachers.htm dynamismchannelmanager.htm dynamismconstructors.htm dynamismdeattachers.htm dynamismdestructors.htm handle.htm handleb.htm menuitemhibehav.htm menuitemhivector.htm menumanager.htm menumanagerbitmap.htm menuverb.htm mousehandlers.htm openawindow.htm prepareMovie.htm purchase.htm resources.htm rollover.htm rules.htm scriptwriter.htm scriptwriterwriteelement.htm scriptwriterwritemultisprite.htm scriptwriterwritemultispritefamily.htm tutorial1.htm tutorial2.htm tutorial3.htm tutorial4.htm tutorial5.htm tutorial6.htm tutorial7.htm tutorial8.htm updateinfo.htm windowmanager.htm windowmanagerbitmap.htm windowmenuelement.htm scriptwriterwritebehavior.htm scriptwriterwritespriteandbehaviorcode.htm scriptwriterwritespritecode.htm tutorial9.htm tutorial10.htm dynamismmiscellaneous.htm