Thanks for everyone's patience in replyin to my tedious, repeated inquiries on
this subject. I've been days and days fumbling with this. As of yesterday, the
mists cleared and finally things are working… I must be super dense as one
would think this could be easier. Any refinements to this feable attempt at a
"guide" will be helpful. We have many issues, all of which lead to challenges
during development for the text only stack newbie. Hopefully newbies lurking
will find this useful:
Here is what I have learned so far, the hard way this past week. (disclaimer
this could be full of erroneous info, or be deprecated in a future release/with
enhancements)
1) Loading text only stacks/behaviors, via some initialization process in stack
A, (whether .livecode or .livecodescript) by any means (get name, go, toplevel
etc), does not make them available in the inspector as a behavior that can be
assigned to any object in stacks B, C, D that may also be open.
2) one can explicitly (obviously) set the behavior to any stack that you know
is currently open:
set the behavior of grc "testBehaviorTarget" to the long id of stack
behavior_portal-links.livecode
BUT:
# the above will fail is the stack is not loaded you will go back and see that
the property inspector shows the behavior is empty.
# the above will fail later if your init methods do not force load those stacks.
3) you cannot set a behavior to a stack disk using a path: this does not work,
even though the path resolves correctly to the right location/stack.. don't
even bother trying this which would make intuitive sense as as the "natural"
way to both set a behavior and call it into memory later… but wrong
conclusions, setting the behavior of an object does not automatically load that
behavior into memory later…
set the behavior of grc "testBehaviorTarget" to the long id of stack
(specialFolderPath("Resources")&
"/shared/behaviors/behavior_portal-links.livecode")
4) if your environment uses a loader to force load, e.g. 10 different
behaviors, by getting the name of each one (or any other method, start using,
toplevel, go)… these
-- may or may not available for editing anywhere in the IDE
-- do not appear in the inspector (i.e. 1 above) as an assignable behavior to
any object in the open stack(s) environment.
5) opening a stack in the IDE during development by double clicking (whether
you set it or not) makes it available in the IDE in the project browser. the
msg box is also a good place to edit front and backscripts. Now you can assign
that behavior to any object in the globally open stacks space manually from the
msg box. But, beware… if you have not included that stack in your loading
initialization procedures, then later it will fail (goes to #2 above) duh, you
assigned it while it was open but later when you re-boot your framework, it is
not in memory.
6) Attempts to set behaviors via path to stack will fail:
the behavior of grc "testBehaviorTarget" to the long id of stack
(specialFolderPath("Resources")&
"/shared/behaviors/behavior_portal-links.livecode")
7) BULLET PROOF 1 FOR THE VISUALLY ORIENTED: knowing all the above and being
aware of all the possible headaches that can occur, one fool proof, "grunt"
method is: explicitly set the stack files of stacks A, B, C, D, E etc to the
same one and only behavior on disk, and now *for sure* the stack is available
in the inspector… where you can look at your object, click and edit the
behavior. TBD: does this add overhead? in theory you only need load the
behavior once… but having it in the stack files prop for multiple stacks… any
negatives? I think not. one assumes the stack files prop are based on relative
paths and this is portable assuming you keep your original directory hierarchy
intact for your builds.
8) BULLET PROOF 2 FOR NERDS: a make sure all your behavior stacks are force
loaded on start up in some initialization handler; then manually the behavior
in the message box for any given object
I hope Monte is watching, because my enhancement request in this area was
confirmed and I believe some fix is in the works… awaiting a new release.
9) EDITING CAVEAT: if you do use .livecode and it opens as a window, OR you
edit the script of an invisible text only stack (not top window) via the script
editor… doing cmd-S, will
a) save changes to disk
b) update your handlers live in the IDE…
BUT! if you have a script open, inadvertently in the IDE and you edit that same
script in a text editor.. if you then later inadvertently save that same stack
from the IDE, all the changes you made in the text editor are overwritten.
(ouch!) but I guess that makes logical sense. But still a caveat
11) editing text only stacks, that are loaded into memory with a text editor
does not automatically, mean that your changes are live in RAM in the IDE… the
IDE only knows the code that was loaded at the time it was loaded… so you can
edit, save and have an expectation for a behavior to fire… but it does not…
(bangs his head on his desk, again…) you have to issue a re-load of all stacks
on disk… (i.e. fire your initialization calls, again, to force the loaders
stack/IDE to re-read the code saved on disk. Serious nuisance
12) For a newbie to text only world of behaviors, start using, backscripts etc…
editing these stack scripts with a text editor, regardless of extension…
therein lies the road to madness (hehe)
12) SAFEST PATH for the newbie
-- make sure all stacks are loaded somehow in the IDE;
-- setting stack files is your best friend: only take a moment and you will
finally see them in the IDE as available for assignment
-- edit all scripts of all stacks in your framework, including even text only
stacks, in the IDE and save them there.
now everything works and I'm finally moving on to developing content instead of
sorting out the architecture.
Please feel free to edit/revise the above… some day we need an official guide
from the mother ship..
Brahmanathaswami
On 7/25/16, 8:34 AM, "use-livecode on behalf of David Bovill"
<use-livecode-boun...@lists.runrev.com on behalf of david@viral.academy> wrote:
Script only stacks are designed from the IDE's point of view as not needing
to show a stack window - as what would be the point as any changes to the
visible appearance are discarded. Consequently the IDE loads the stack as
an invisible stack, and will often open the script in the script editor
without showing the stack window. If needed you can use "show" or "set the
visible" - toplevel may work as well. Double clicking on a script-only
stack in the finder never produced reliable results for me - so I do this
from within the IDE.
An aspect of this issue is that xxxx.livecodescript stacks are not
registered with Spotlight on OSX - my guess is that the devs need to
register this extension in the Livecode app bundle or similar as well?
_______________________________________________
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
