Creating a button behaviour

October 9, 1997
by Alex Zavatone

With all the new features in Director 6, one would think it to be a piece of cake to create a behavior that would function perfectly as a generic button.

Reality dictates otherwise.

In creating a simple two state button that highlights when clicked on and behaves properly when the mouse is dragged on and off it, there are several things to consider. First of all, there are new events in Director 6 that help this along, MouseEnter and MouseLeave. (Why they didn't call it mouseExit, I'll never know). These events get triggered when the cursor enters and exits the sprite that they are attached to. So in addition to the standard mouseDown and mouseUp events and the behavior description handler, the basic behavior would look like this:


on mouseDown me

end

on mouseUp me

end

on MouseLeave me

end

on MouseEnter me

end

on GetBehaviorDescription
  return "generic button script"
end getBehaviorDescription

Ideally, one would think that you could just place the appropriate lingo within the handlers and you'd be done but things are rarely that easy in lingo. The problem is that to create proper two state button behavior, the mouseLeave and mouseEnter scripts have to know if the mouse was pressed down on the button itself. This will require the creation of a state variable that stores the status of "did the user mouseDown on the sprite?" Since behaviours can contain properties, this requires that the following lingo be applied to the beginning of the behavior:


property pMouseDownOnMe

on new me
  set pMouseDownOnMe = 0 
  return me
end

Then in the mouseEnter and mouseUp and mouseLeave scripts, the state of the "pMouseDownOnMe" variable is checked to make sure to do the proper thing when those events are triggered.

If we were to put the script together now, we'd be almost all the way there. A Pass command needs to be included at the end of every hander so that any events will get passed back to any cast script that out sprite's member may contain. Finally, we have enough information to build a script that will function properly as a two state button. Below is a sample that will move the sprite by 2 pixels.


-- generic button script
-- Alex Zavatone '97

property pMouseDownOnMe

on new me
  set pMouseDownOnMe = 0 
  return me
end

on mouseDown me
  set pMouseDownOnMe = 1
  set myCastlib = the castlibnum of sprite the clickOn
  set the loc of sprite the clickOn ¬
    = the loc of sprite the clickon + 1
  updatestage
  pass
end

on mouseUp me
  if not pMouseDownOnMe then return
  set pMouseDownOnMe = 0
  set myCastlib = the castlibnum of sprite the clickOn
  set the loc of sprite the clickOn ¬
    = the loc of sprite the clickon - 1
  updatestage
  pass
end

on MouseLeave me  
  if the mouseUp or not pMouseDownOnMe then return
  set myCastlib = the castlibnum of sprite the clickOn
  set the loc of sprite the clickOn ¬
    = the loc of sprite the clickon - 1
  updatestage
  pass
end

on MouseEnter me
  if the mouseUp or not pMouseDownOnMe then return
  set myCastlib = the castlibnum of ¬
    sprite the clickOn
  set the loc of sprite the clickOn = ¬ 
     the loc of sprite the clickon + 1
  updatestage
  pass
end

on GetBehaviorDescription
  return "generic button script"
end getBehaviorDescription

This script can easily be changed to switch between two adjacent cast members by replacing the line that starts with


set the loc of sprite the clickOn... to 
set the member  of sprite the clickOn ¬ 
    = member ((the membernum of sprite the clickOn )¬ 
- 1) of castlib myCastlib

in mouseLeave and mouseUp and


set the member of sprite the clickOn = ¬
    member ((the  membernum of sprite the clickOn)¬ 
    + 1) of castlib myCastlib

in mouseDown and mouseEnter.

This script can also easily be edited to function as a 3 state button with an up state, a down state and an up and rolledOver state. That one I'll leave up to you. There is one more thing to consider though. For proper operation of your specialized mouse behaviors, you should use the concept of the state variable in your other behaviors that execute the button's commands. Otherwise, you will have scripts with properly functioning UI but with commands that can be executed by mistake.

A Director user since 1987, Alex (Zav) Zavatone has worked on the engineering teams for both Director and Shockwave, 4, 5, 6 and 7. Recent investigations find him developing foundation classes for Director with asynchronous process management and other life threatening activities. In its early days, he had something to do with this Internet thing known as "DOUG". A noted ne'erdowell, slacker and laggard, Mr. Zavatone is nonetheless is trusted by children, small animals and the elderly. In his spare time, Mr. Zavatone rehabilitates lame desert trout.