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 <bonnm...@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 <
> ambassa...@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
> > ____________________________________________________________________
> > ambassa...@fourthworld.com http://www.FourthWorld.com
> >
> > _______________________________________________
> > 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
> >
> _______________________________________________
> 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
>
_______________________________________________
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
