See Also
"6: Handle" Behavior

Site Nav

• Home
• Tutorial Docs
  • 1: Creating Windows
  • 2: Creating Menus
  • 3: The Score
  • 4: wfsAddElementToManager
  • 5: wfsSetParent, wfsSetChild
  • 6: wfsWriteMultiSprite
  • 7: wfsWriteMultiSpriteFamily
  • 8: wfsWriteElement
  • 9: Dynamism API
  • 10: Dynamism API (cont)
• Window Docs
  • 1: prepareMovie
  • 2: Window Manager
  • 3: Window Manager
  • 4: Win/Menu Element
  • 5: Close My Window
  • 6: Handle
  • 6b: Handle
  • 7: Open A Window
  • Drag Element
  • Drag Element b
  • Close A Window
  • Rollover
  • Cursor Control
• Menu Docs
  • 1: prepareMovie
  • Menu Manager
  • Menu Manager
  • 4: Win/Menu Element
  • Menu Verb
  • 6: Handle
  • 6b: Handle
  • 7: Open A Window
  • Drag Element
  • Drag Element b
  • Menu item highlight
  • Menu item highlight
  • Rollover
  • Arrow for menus
• Dynamism
  • Script Writer
  • wfsWriteMultiSprite
  • wfsWriteMultiSpriteFamily
  • wfsWriteElement
  • wfsWriteSpriteCode
  • wfsWriteBehaviorCode
  • wfsWriteSpriteAndBehavior
  • Dynamism
  • Dynamic Channel Mgr
  • Constructors, Attachers...
  • Destructors
  • Miscellaneous
  • Limitations, Bugs
• Other Docs
  • Mouse Handlers & WFS
  • Troubleshooting Rules
  • API Index
  • Director Resources
• Update Info
• Credits
• Purchase

css drop down menu by Css3Menu.com

6b: Handle

The "6b: Handle" parent script

• What it does
• Deeper
• "6b: Handle" child object creation is automatic

What it does

This works in conjunction with the "6: Handle" behavior. If you use the "6: Handle" behavior, you need to also drop a copy of the "6b: Handle" parent script in a cast. If you use the "6: Handle" behavior without dropping the "6b: Handle" script in a cast, WFS will remind you about it.

Deeper: What it does

In WFS 3.0, each "6: Handle" behavior had an 'enterFrame' handler. This handler was subsequently eliminated from the "6: Handle" behavior. Instead, on mousedown, the "6: Handle" behavior notifies a "6b: Handle" child object (named gWFSHandle, a global variable) that it is active. The "6b: Handle" child object has a stepFrame handler. The stepFrame handler processes active handles.

This means you can attach as many "6: Handle" behaviors to different sprites as you like, and it doesn't degrade performance, ie, however many "6: Handle" behaviors you use, only one stepFrame handler per frame is executed, and when it executes, it deals with only instances of "6: Handle" that are active in dragging a multi-sprite around.

This is the only frame event in WFS, ie, the computational overhead of WFS is very low indeed.

"6b: Handle" child object creation is automatic

If you look in the prepareMovie handler in the "1: prepareMovie" movie script, you see the below code:

if wfsMemberExists(member("6b: Handle")) then
    gWFSHandle=new(script "6b: Handle")
    add the actorList, gWFSHandle
end if

In other words, if a cast contains the "6b: Handle" script, the prepareMovie handler creates gWFSHandle and adds it to the actorList so it receives stepFrame messenges. You don't need to add any Lingo to your project to get this working.

If the "6b: Handle" script is not present and you do use the "6: Handle" behavior, WFS reminds you to drop the "6b: Handle" script in a cast in the beginSprite handler of "6: Handle".