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