Initializing Libraries

Sannyasin Brahmanathaswami brahma at hindu.org
Tue Jul 26 18:28:07 EDT 2016


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-bounces at lists.runrev.com on behalf of david at 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?



More information about the use-livecode mailing list