Parent of Target

[Sannyasin Brahmanathaswami]

@ 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!

+1!

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

Where: 
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 related.

[/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-bounces at lists.runrev.com on behalf of use-livecode at 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.