@ Jacque   the behavior is attached to a stack that is not the same stack as 
the target (a download button) so "this me" won't work

@ Bob  " getParentStack(the long id of me). All it does is parses the long id 
by using wordOffset to find the word "stack" then returns word tWord to -1 of 
the long id. Pretty basic."

Awesome: this has been added to the main backscript utilities section… Nandri! 
(thank you)

@ Monte & Richard

" Monte Goulding wrote:

> I have actually thought about whether it would be reasonable for `the
> long id` to return such an object reference as it would stringify
> automagically if necessary....I think complex objects that handle many
> object references and the IDE would have a significant bump in speed
> if we did such a thing.

Oh yes please!


Addendum on Scoping

This new "modular" world, of behaviors, libs that have been put into msg path 
with "start Using" or "insert into back".. text files, multiple binary.livecode 
stacks -- not substacks as such, but separate.livecode files.
The app is now a complete "environment/framework". With Andre constant warnings 
along with my experience using globals in this environment gets very dangerous 
very fast, typically want to use an array to starts holding all kind of things 
we think we need to reference across many different stacks/libs. Seems OK on 
the surface, but then as Andre says, if  someGlobalArray["fruit"]  = "apple" 
when you thought for sure it should now be "orange" then then debugging "hell" 
door opens. So instead we start sending and dispatching commands, setting up 
locals in scripts with lots of small 

local sCurrentFlavorA

function returnCurrentFlavor
   put sCurrentFlavorA["fruit"]
end  returnCurrentFlavor

So now, with debug on you can trace easily where things are happening.  so some 
way to track, not only "where did this come from" (which is what debug stepping 
is really doing) but to look "up"   "Who is asking?"  
would be interesting.

Somehow I think this relates to another Idea I keep having: which is 

place group [custom control]  "downloading" of stack "customControlsLibrary 
onto this card

a) group "downloading" has progressField, progressTitle, progressBar (ala the 
lesson on line for load URL which I just copied to the SivaSiva app and 
modified yesterday) i.e. a customcontrol
b) that group has a behavior 
c) that it can be made to magically appear and disappear "anywhere at any time"
d) such that one update updates all future instances.

OK well now we can do that by copying the group dynamically and since after the 
standalone is built, that group is never saved.. "kinda" works, but in dev I 
keep getting multiple copies of this group in different stacks… 

i.e we already have this with  icons for buttons… you can have a single image + 
ID for a button that appears on multiple stacks.. change the image and all 
buttons change.  So why not a phantom group whose "real" presence is a single 
instance in another stack.   

Perhaps this has nothing to do with the parent of target; but seems all vaguely 

[/end of babbling about what I do not really understand very well]

On 8/9/17, 6:25 AM, "use-livecode on behalf of Bob Sneidar via use-livecode" 
<use-livecode-boun...@lists.runrev.com on behalf of 
use-livecode@lists.runrev.com> wrote:

    getParentStack(the long id of me). All it does is parses the long id by 
using wordOffset to find the word "stack" then returns word tWord to -1 of the 
long id. Pretty basic.

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to