Strange contents of long name

[Peter Haworth]

Well after reading this and Alex's post, I think this is a bug since the
hierarchy of owners is not being observed.  It's kinda like delivering mail
to the first street number and name found in any city rather the one in the
address city :-)

Be that as it may, I concur that using ids is much better than using names
but the context of what I'm trying to do (in case there's a better way) is
to check if a given control is a component control of a datagrid.  There
are certain groups in a datagrid which are always present so I was checking
the long name of the control to see if it contained any of those group
names.  That's when I discovered the anomaly of controls with empty names.

I had planned on changing the code to check if the control name is empty
and if so, chase up the owner hierarchy looking for the group names I'm
interested in instead of checking the long name.  However, there doesn't
appear to be a way to find out of the name is empty since getting the
name returns the default "field id xxx".  Aaargh!

All this on the unproven theory that it's quicker to check the long name
than chase up the owner hierarchy in a repeat loop.

Datagrid controls have a property that identifies them as data grids but
unfortunately their component controls don't.  (Reminder to self - if I
ever design any custom controls, take heed of that!).


Pete
lcSQL Software <http://www.lcsql.com>


On Wed, Jan 16, 2013 at 3:40 PM, Geoff Canyon <gcanyon at gmail.com> wrote:

> On Wed, Jan 16, 2013 at 3:36 PM, Alex Tweedly <alex at tweedly.net> wrote:
>
> > I've always realized there was an issue if  the two contols with the same
> > name were at the same level in the control hierarchy - but that is always
> > easily avoidable, and seems (almost) acceptable since they have an
> > ambiguous long name; I hadn't realized there was this issue with
> differing
> > levels in the control hierarchy. And in this case there is no long name
> > ambiguity, and there is also no guarantee of being (easily) able to avoid
> > it, since you have less visibility of control names within "custom
> control"
> > groups.
>
>
>
> I'll be happy to be proven wrong, but I don't think there is *any sure way*
> to reference a control, given only its long name in a stack that isn't
> entirely under your control. Examples would include if you're writing
> compound controls, or a development tool. For example, suppose your
> hierarchy is like this:
>
> stack "kettle"
> card id 1002
> group "ted"
> |  group "alice"
> |  |  button "bob"
> |  button "Button"
> group "alice"
> |  button "bob"
>
> (still using Navigator ten years after I stopped working on it...) Then if
> you type this in the message box:
>
> set the label of btn "bob" of group "alice" of stack "kettle" to "HA"
>
> The button two levels deep will change its label, despite the fact that you
> didn't type of group "ted". This is possible to *any* depth of groups,
> making it *impossible* to prevent it completely, although you can make it
> very unlikely, obviously. As I said, I don't think there is any way around
> this.
>
> Long IDs are your friend here, especially given that you can use them so
> cleanly in a variable:
>
> set the label of tID to "HA"
>
> This works a treat, although you have to watch out for changing file
> references if you store a long id from one session to the next (and maybe
> even during a session? I haven't checked).
> _______________________________________________
> 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
>