Sannyasin Brahmanathaswami wrote:
> On March 30, 2016 at 6:17:20 PM, Richard Gaskin wrote:
>
>> in brief:
>> 1. Open them
>
> # this did not work for me earlier today
What exactly happened?
It may be helpful while demystifying this to work with ordinary stack
files for your behavior scripts. There's really no difference between
ordinary stack files and script-only stack files beyond the storage
format, but if nothing else sense you're already confident in your use
of normal stacks it may help you focus on the things that may actually
be the source of the problem.
In this case, with opening a stack used as a behavior script, I'd guess
that the problem wasn't that the stack couldn't be opened, but that it
failed to resolve as a behavior for another object.
If that hunch is correct then the problem isn't with the script-only
stacks or even how you opened them. The problem is with the strangely
finicky way behaviors are resolved. As I wrote yesterday:
NOTE: a long-standing source of confusion and frustration with
behaviors is that the object holding the behavior script must
be in memory when any stack containing objects subscribed to it
is loaded.
When behaviors are in the same stack file the engine figures it
out on its own. But if the behaviors are in a separate stack
file (regardless of whether it's script-only or normal) that
separate stack file must be in memory first.
In some cases this can mean introducing a new stack only for
the purpose of loading your others so that they load in an
order that will allow behaviors to be resolved correctly.
Another option is to write a script that works on preOpenStack
and walks through each object setting the object's behavior
property to the object's behavior property, which forces
resolution of the information already known to the engine but
not loaded in the finicky order it requires.
A request to simplify this has been submitted:
<http://quality.livecode.com/show_bug.cgi?id=8993>
Given that this finicky quality has been around as long as parentScripts
themselves (er, "behaviors" <g>), I don't expect to see it addressed
soon. Would be nice, but there are bigger fish to fry with v8 right now.
So we just need to make sure that anything containing a behavior script
is in memory when anything that relies on that behavior script is put
into memory.
Review the sequence of stack opening you'd tried earlier and see if
that's not what had caused your earlier problem with opening the
behavior definition stacks.
>> 2. Read any property from them
>
> # have yet to try that..
It's kinda handy sometimes because it needs to unpack the stack file to
be able to obtain a property value, but since it's not truly opening the
stack per se it never shows visibly and doesn't trigger the open-
messages (preOpenStack, preOpenCard, openStack, etc.).
> 3. Adding stack files and restarting the stack works
The stackFiles is an old property predating behaviors, but useful for
many things like image ID resolution and more - a good fit for any
problem where you have multiple stack files used by a single stack that
relies on them.
I rarely use it because my runtime setup is very different from my
development setup (most external stack files are used on multiple
projects and reside in a very different folder from the relative
position they'll be to the app's mainstack when deployed). But I miss
it. Very handy.
> Forgive me for seeming to be obtuse. It's partly deliberate because
> the discourse is opaque enough to make using script-only stacks for
> behaviors challenging -- gaps in the picture of "exactly what should
> I do?" so I thought we might get some "ghee" out of the churn --
> clear instructions, for everyone -- and also because I really want to
> go this modular direction so I tend to dig, dig, dig until all the
> worms are out of the can and crawling on the table. Gold may appear.
It can seem daunting when you're making so many changes at once, since
that makes it hard to pin down the root cause of an issue.
But I think we can boil down text-optimized development in a few simple
guidelines:
1. Use libraries for as much global availability as practical,
and use behaviors for as much object-specific availability
as practical.
2. When using behaviors, the object containing the behavior script
must be in memory when anything relying on it is brought into
memory.
3. A library can be any stack, regardless whether it's a mainstack
or substack.
4. A behavior definition can be any button or stack.
5. The format of the stack on disk (whether saved as an ordinary
binary stack or as a script-only stack) only affects what gets
saved in the file, but has no affect on how we work with them
in memory.
Far harder than any of this is learning to use GitHub. :)
> I did read your post and I did try to put my script-only stack into
> memory by using "open" in the preopenstack of the main stack.
>
> But it did not work. The child called out, (mouse up on field) but
> the parent didn't hear it even though he was in the room (in memory
> via "open)
I suspect that's because of the loading order (#2 above). But let us
know if you find otherwise.
> I will test again tomorrow after letting LC8 rest over night. The
> LC8 IDE has a referencing issues... and is "losing the target" in
> a number of scenarios. Like the case of deleting an object on your
> card and watching while a button in the inspector palette disappears
> instead. Msg path gone awry until you restart. The failure of mouseup
> to not trigger the behavior when the parent stack is in memory
> already... smells like a similar fish...
Please report those, or if already reported add your notes confirming
the issue.
For most of LC's life there has only ever been two versions: current
and past. Current is whatever is in development, and the past is
whatever used to be in development and reached end-of-life when a newer
version becomes current.
During this long process of moving from the v5-and-earlier world into
the modern world that can fulfill the Kickstarter goals, we've
temporarily been indulging in a very expensive process in which the team
has been maintaining three very different versions (6,7, and now 8)
simultaneously. There were good reasons for this, given the scope of
monster tasks like Cocoa, Unicode, and others, but it's unsustainable.
It's time to return to the normal world most software projects have, and
LiveCode used to have, in which there is only one version in active
development.
It's critically important that issues found in v8.0 be reported and
addressed. If reports add another week or two to the development cycle,
that's far better than releasing it and having those issues still present.
Please do report issues you find. It takes only as much time as
describing them here, but makes them actionable for the team so they can
be resolved.
> I agree BTW -- "parent" is a much more helpful term.. we use that in
> CSS and XML... so why not here? I've even start replacing "behavior"
> with "parent" in my head, as it helps keep things straight.
I believe it's more specific and less ambiguous (so many properties
alter the behavior of an object; the word "behavior" is so very broadly
used that it makes writing about that specific property somewhat
cumbersome at time). "ParentScript" was the original name for the
property and last I looked it remains a reserved token.
But we're so far down this road with the newer "behavior" that I think
we're just stuck with yet another learning impairment in the language
going forward.
Oh well. Better than not having the feature at all.
> POINT: though you may not want to overload the dictionary, something
> more is needed. Who has contributing rights? I could give is a
> shot (much more concise.)
That would be most welcome. They made a blog post with the relevant
links introducing the process of community enhancement of the docs:
<https://livecode.com/putting-the-you-in-documentation/>
> Mahalo for your near-infinite patience!
Happy to help. Just paying it forward. You should have seen some of my
posts on the MetaCard list circa '98. I was moving from SuperCard,
where we only had a single custom property set, and was having a very
difficult time wrapping my head around the syntax for working with
multiple property sets. Kevin Miller and Scott Raney were far more
patient with me back then than I've ever been. :)
--
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
