Site Nav
css drop down menu by Css3Menu.com
WFS 4.0a as it appears in the
Director Library Palette
|
Home
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 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.
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
System Requirements
Macromedia Director 8.5+ (Mac or PC)
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.
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.
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.
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:
- 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.
- Then peruse the documentation concerning each behavior and other
WFS elements.
- 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.
- 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.
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.
|
1: prepareMovie
2: Window Manager
3: Window Manager
4: Win/Menu Element
5: Close My Window
6b: Handle
Menu Manager
Menu Manager
Menu Verb
Menu item highlight