Director Web : Tips n' Scripts : OOPs

Double Click Handlers with Parent/Child Scripts

Date:    Wed, 27 Sep 1995 05:39:53 -0500
From:    "Glenn M. Picher" <gpicher@maine.com>
Subject: double click handlers (solves: order the effects of updatestage)

The following general-purpose cast script mouse handlers broaden the conceptual possibilities for double-click handling in Lingo. They are not rigorously tested, but they seem to work for me. On any problems, I'd greatly appreciate a report of some kind. They use parent/child programming techniques but you don't really need to understand how. Just modify the "on singleMouseDown", "on singleMouseUp", "on doubleMouseDown" and "on doubleMouseUp" handlers as needed.

global doubleClickObject
property wasDouble

on birth me
  set the wasDouble of me to 0
  return me
end

on mouseDown me, wasQueued, queuedUp
  if not voidP(wasQueued) then
    --The mouseDown event has gotten here via a time out,
    --not an actual click. Stop the time out clock.
    set the timeOutScript to ""
    set the timeOutLength to  10800
    --code for single click's mouseDown goes here...
    singleMouseDown()
    --end code for single click's mouseDown
    --dispatch the mouseUp again if necessary for a single click
    if not voidP(queuedUp) then
      set the wasDouble of doubleClickObject to 0
      mouseUp(doubleClickObject)
      return
    end if
  end if
  if the timeOutScript = "" then
    --queue the event, waiting for a time out
    set doubleClickObject to birth(script (the castnum of sprite (the clickOn)))
    set the timeOutLength to 30
    set the timeOutScript to "mouseDown(doubleClickObject,1)"
    return
  end if
  set the timeOutScript to ""
  set the timeOutLength to 10800
  set the wasDouble of doubleClickObject to 1
  --code for double click's mouseDown goes here...
  doubleMouseDown()
  --end code for double click's mouseDown
end

on mouseUp me
  if the timeOutScript = "mouseDown(doubleClickObject,1)" then
    set the timeOutScript to "mouseDown(doubleClickObject,1,1)"
    return
  end if
  if the wasDouble of doubleClickObject = 0 then
    --code for single click's mouse up goes here...
    singleMouseUp()
    --end code for single click's mouse up...
    return
  end if
  set the wasDouble of doubleClickObject to 0
  --code for double click's mouseUp goes here...
  doubleMouseUp()
  --end code for double click's mouse up...
end


--customizable handlers

on singleMouseDown
  put "single" into field "down status"
  updateStage
end

on singleMouseUp
  put "single" into field "up status"
  updateStage
end

on doubleMouseDown
  put "double" into field "down status"
  updateStage
end

on doubleMouseUp
  put "double" into field "up status"
  updateStage
end

This approach would allow you to implement radically different visual appearances and behaviors based on the type of click. Tim Fullerton, for instance, could update whatever sprites and play whatever sound necessary within the customizable handlers.

Caveats:

For "the clickLoc" to function properly, you must have at least an empty sprite script "--" in the sprite's channel ("the clickLoc" is used to identify which cast member to birth an object from). The handlers could be rewritten to use sprite scripts instead of cast scripts, or to otherwise locate a parent script.
The example functions use text fields named "up status" and "down status" (I used this while debugging on-screen). The customizable handlers don't need any particular Lingo.
The timeOutScript is used to defer action on mouse clicks. The handlers could be modified to have fewer side effects on other parts of a project that might use the timeOutScript and related Lingo keywords (by preserving & restoring values).
If you want to use the mouseWord, the mouseLine, and similar keywords, you might need to modify the handlers to store that information in the actual mouseDown event (as global variables or as additional properties). I'm not sure if they'd function as expected in the customizable handlers.
The actual calls to singleMouseDown() (and possibly to singleMouseUp() as well) are not part of the mouse event heirarchy-- they are generated from a parent/child method which happens to run the same Lingo code. Consequently, pass and dontpassevent won't work as you might expect. Nor does the stillDown; and don't assume the mouseDown is actually true when singleMouseDown() runs or false when singleMouseUp() runs.
The double click length and default time out length are hard coded. These could easily be made globals or properties.
I have a feeling I may be breaking someone's rules of good programming style when it comes to object names or method arguments. I'm just getting up to speed on parent/child scripting. Any slaps on the wrist would be appreciated.