Sannyasin Brahmanathaswami wrote:
> I think the idea that you have to open an external behavior stack
> *before* you open the main stack that has controls which point to
> it as their parent, is totally unintuitive and when a newbie reads
> "load, open, put into memory" etc... he/she will always assume this
> can happen in the preopenstack handler.
Perhaps. Ideally we'd need to user-test that to affirm the assumption.
It wouldn't have occurred to me, but I've spent too long using xTalks to
be a reliable gauge of what it takes to learn them (which is why the
older I get the more ardent I've become about listening carefully to
people who know nothing about the software; that precious naivety leaves
so quickly, and is invaluable during that brief moment it still exists).
The one thing everyone agrees on is that the current need to be so aware
of load order for behavior resolution is undesirable and needs to be
changed at first opportunity. Mark Waddingham doesn't much care for it
any more than you or I do. I'd be surprised if it isn't resolved (all
puns intended) by 8.2 if not sooner.
Fortunately we have the convenient stackFiles property to make this a
bit simpler in the meantime.
> "Load "MyBehaviorStack" into memory without opening it. "
>
> It is or is not open after you query the property? do you really mean:
>
> "You can query a property to open the stack in the background and put
> its stack script into memory."
Whether a stack is "open" if loaded into memory without using an "open"
or "go" command is perhaps a philosophical question.
Personally I try to use "open" to describe a stack's runtime state only
in cases where I brought it into RAM with "open" or "go", and the rare
case of anything else as simply "in memory".
> a) b) (with explanation above) c) below + Jacque's explanation could
> go in the dictionary... I don't think that's over loading it. had
> that been what I read at Git Hub, we could have avoided several days
> for lost time.
Go for it, but please be brief in Dictionary entries. This thread is
as long as it is in part because of a misunderstanding of what "start
using" does, which may merit mention there but on the other hand if we
included caveats in every Dictionary entry to cover mistakes I've made
trying to misapply commands it would be a tome too hefty to read. :)
Rather than enumerate all possible ways do not do something, just focus
on what you want them to do.
> OTOH, we did get the gold out of it: your nested behaviors/as-
>classes tutorial...
>
> So it was all worth it!
Glad that was helpful. Nested behaviors are da bombdiggety!
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
