Extracting a reference to a stack

[Mike Bonner]

Ah thats too bad.
I guess the other idea could still work. Dispatch a message to the object
in question.

Change getprop to..

command owningstack
  return the name of this stack
end owningstack

To get at the information just
dispatch "owningstack" to myLongId
put the result

I have a feature request..  The ability to return a long id as an array
keyed by numeric order AND object type of possible. Keys something like
1b,2g,3g,4g,5s,6s.  1b would be the button in question, that is in group 3
nested groups, on a substack of the mainstack.  6s would contain the
mainstack reference.  In this way it should be easy to pick out what you
want, and obviate the need to worry about namings that throw so many other
things off.

Also, it just occurred to me.. Messages can be passed.. (doh)

So would it be possible to dispatch a message (that is in a library) that
grabs the id of a level, then pass to the next, and build a reference list
that way?

IE  dispatch it to button 1 of group 1 of substack 1 of stack 1 .. passing
it each step of the way until the mainstack is hit?

On Sun, Aug 9, 2015 at 10:26 AM, Richard Gaskin <ambassador at fourthworld.com>
wrote:

> Mike Bonner wrote:
>
>> Ok. Better way.  Use a virtual getprop in a library stack
>>
>> getprop owningstack
>>    return (the name of this stack)
>> end owningstack
>>
>> Then if you have the long id of an object you can do this..
>> get the owningstack of myLongId
>> and "it" will contain the stackname.  (should also work inserted into
>> front, right?)
>>
>
> An excellent suggestions, but suffers from a design limitation not of your
> making:  getProp and setProp are currently handled as system messages, so
> when lockMessages is true they won't fire.  This makes them unpredictable
> except in cases where you have total control over all code (no third-party
> libraries, and much discipline among team members). :(
>
> Mark Waddingham has expressed the opinion that getProp and setProp should
> be recategorized as custom handlers, and given how they're used that seem
> quite reasonable.  As custom handlers they'd be immune to lockMessages.
>
> If the engine were updated accordingly they'd become extremely valuable in
> so many cases, but as they are I rarely use them.
>
> I don't know when such a change would take place.  I had hoped it would be
> before now.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>