Associated Email list Windows_For_Shockwave
What it is
Windows For Shockwave is a set of Library Palette behaviors for Director 8.5+ (not an Xtra) that enables
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 mediamacros.com 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 director-online.com. 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.
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.
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.
Click to purchase and download WFS 4.8
Macromedia Director 8.5+ (Mac or PC)
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:
The documentation consists of four types:
Learn how to use WFS like this:
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.