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

Tutorial 5: wfsSetParent and wfsSetChild

Tutorial 5: wfsSetParent and wfsSetChild

If you check out scene 9 in the feature tour (the source code for which is in WFS48x.DIR in the 'samples' folder of your WFS documentation) you see that when you drop blue window B on another blue window A, then A becomes the parent of B.

The source code is kind of complicated (though well-documented), but that is only because there is logic that

1. checks to see what windows the blue window has been dropped on;
2. selects the highest window it has been dropped on that also has the parent-switching logic associated with it (Maybe you drop a blue window on a window that doesn't have the parent-switching logic associated with it, ie, drop it on a window that isn't blue. Then you don't want to switch the parent.);
3. and then makes the result look like a tree. It's really this last step that makes the source code relatively complex.

The point of scene 9 is actually much smaller than the code associated with it. Scene 9 was made to illustrate use of the wfsSetParent handler and the wfsSetChild handler. I got kind of carried away seeing if I could make a tree-control type of thing. I would say that WFS is better suited for windowing than making windows out of tree control elements. But even in windowing you sometimes need to change parent-child relationships at run-time.

The wfsSetParent handler lets you set/change the parent of a multi-sprite at run-time. The wfsSetChild handler lets you make a multi-sprite be a child of another multi-sprite. Really, these two operations do the same thing. When you set the parent of multi-sprite B to be multi-sprite A, that's the same thing as setting multi-sprite B to be a child of multi-sprite A.

Both of these handlers are defined in the "3: Window Manager" and "Menu Manager" behaviors.

If you look at the HTML documentation of wfsSetParent and wfsSetChild, you see that how to call them and what they do is pretty well-documented. Check out the diagrams in the wfsSetChild documentation. Don't be intimidated by the relative complexity of the source code of scene 9. Changing the parent-child relationships between multi-sprites is very simple, a one-liner, unless you want to create something like a tree control type of thing in which case the bulk of the logic is in making it look like a tree.