Extracting a reference to a stack

[Peter Haworth]

I guess how you approach this is a matter of coding preferences.  All the
solutions posted work but some of them have certain edge cases when they
won't, most of which I've run into at one time or another.  I still prefer
using the engine's knowledge of the ownership hierarchy of an object since
it will always be correct and I've found the following to work for any
stack in memory no matter whether it's the topstack, whether it is open, or
whether a long id or long name is passed as its parameter..

function stackOfObject pobject

   repeat
      if word 1 of pobject is "stack" then
         return pobject
      else
         put the long owner of pobject into pobject
      end if
   end repeat

end stackOfObject

I like the idea of having a built-in function that returns an array of the
ownership hierarchy.  While not quite what Mike suggested, the above could
be modified to return an array as follows.  I'm sure there are many other
ways to do it.

   function ownershipArray pobject

   local tArray,tGroupLevel

   put zero into tGroupLevel

   repeat
      if word 1 of pobject is "stack" then
         put the short name of pobject into tArray["stack"]
         put the mainstack of pobject into tArray["main"]
         put the filename of stack (the mainstack of pobject) into
tArray["file"]
         return tArray
      else
         if word 1 of pobject is "group" then
            add 1 to tGroupLevel
            put the short id of pobject into tArray["group"][tGroupLevel]
         else
            put the short id of pobject into tArray[word 1 of pobject]
         end if
         put the long owner of pobject into pobject
      end if

   end repeat

end ownershipArray

If you pass the id of a button nested in three groups, this would return
the following keys:

button
group
   1 --innermost group
   2
   3 --outermost group
card
stack
main
file



On Sun, Aug 9, 2015 at 9:40 AM Mike Bonner <bonnmike at gmail.com> wrote:

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