Library Stacks PART II

Ken Ray kray at sonsothunder.com
Sun Feb 29 19:37:38 EST 2004


Kevin,

> 1.  There is no construct  simular to Visual Basic where a 
> project file controls the included stacks aka handlers (thus 
> those stacks in project are in the message path). 

There is no "project file", true, and I understand this is a different
paradigm and a bit hard to grab hold of. But perhaps this will help:

The message passing hierarchy is as follows. Note that some people see
messages going "up" through the hierarchy (like a helium-filled
balloon), and other see messages going "down" through the hierarchy
(like dropping a stone). Personally I see them going "up", but for this
example it seems easier to show messages going "down" from the target
object and if not trapped being passed to the next object in line):

   frontScript(script of object inserted "into front")
     |
   object
     |
   group (with backgroundBehavior turned off)
     |
   card
     |
   group (with backgroundBehavior turned on)
     |
   substack (stack script - if it exists)
     |
   mainstack (stack script)
     |
   library stack (the stack script of any stack "in use")
     |
   backscript (script of object inserted "into back")
     |
   Revolution engine

I won't get into frontscripts and backscripts at the moment, but as soon
as you put a stack "in use" (through the "start using" or "library"
command), its stack script is immediately inserted into the message
passing hierarchy and it receives messages that are not trapped by
"higher level" object. If you have a handler in a button that says:

  on mouseUp
    DoStuff
  end mouseUp

and then click on the button, the "DoStuff" command will start
Revolution engine looking for a handler to trap this message. As it goes
from the object "down" through the objects in the current containment
hierarachy (group/card/substack/stack) looking for a handler for
"DoStuff". As soon as it exits the mainstack, it then looks through
*all* of the stack scripts of the stacks that have been put "in use" (or
libraried) looking for a hit. If I have three stacks in use, and the
second one has this handler:

  on DoStuff
    answer "got it!"
  end DoStuff

I'll get the answer dialog showing up. If you want to handle the message
and then allow other objects in the message passing hierarchy to get a
crack at handling the message as well, you use "pass <handlerName>". So
using my example again:

-- Button on card:
on mouseUp
  DoStuff
end mouseUp

-- stack script of stack that "owns" the card that "owns" the button
on DoStuff
  answer "I got it!"
  pass DoStuff
end DoStuff

-- stack script of stack "libOne" put into use through "start using"
on DoStuff
  answer "I got it too!"
  pass DoStuff
end DoStuff

-- stack script of stack "libTwo" put into use through "start using"
on DoStuff
  answer "Me too!"
  pass DoStuff
end DoStuff

When I click on the button I'll get three dialogs and then an error from
Revolution (because I passed the "DoStuff" message that eventually made
its way to the Rev engine and it didn't know what "DoStuff" was). To
eliminate the error, I simply need to make sure that the last object to
get the message doesn't pass it.
 
> 2.  A start using from multiple stacks (main or sub) for the 
> same library will cause a unnerving message from RR.  

True. As you can see above, you only need to start using *once* for each
stack, and then it is available from that point on to all stacks that
are open.

> How do I use a libray wich I wish to include from all my 
> stacks without experiencing this error? 

Well as I mentioned above, you only need to load it once, but if for
some reason you have a stack that opens that needs to use a certain
library and isn't sure whether the supporting library has been loaded or
not (and if not, it will load it itself), you can check the
libraryStacks (or the stacksInUse) and see if the library exists. For
example:

on preOpenStack
  if "libOne" is not among the lines of the stacksInUse then
    start using "libOne"
  end if
  -- (etc.)
end preOpenStack

> Is it practical (is RR open enough) to modify the 
> distribution builder and ide to support project files?

It depends on if you can provide some advantage to what's already there.
You can certainly request and enhancement by logging it in Bugzilla with
a type of "enhancement".

HTH,

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/ 




More information about the use-livecode mailing list