Strange contents of long name

Scott Rossi scott at
Wed Jan 16 19:33:11 EST 2013

I would suggest a loop of checking the owner of the control until you find
(or don't find) the data grid property of the parent group.

FWIW, if you still want to determine if a control has no name, you might

-- pControl is the long id of a control
function unamedControl pControl
  return (name of pControl = abbrev id of pControl)
end unamedControl


Scott Rossi
Creative Director
Tactile Media, UX Design

On 1/16/13 4:14 PM, "Peter Haworth" <pete at> wrote:

>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
>to the first street number and name found in any city rather the one in
>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
>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!).
>lcSQL Software <>
>On Wed, Jan 16, 2013 at 3:40 PM, Geoff Canyon <gcanyon at> wrote:
>> On Wed, Jan 16, 2013 at 3:36 PM, Alex Tweedly <alex at> wrote:
>> > I've always realized there was an issue if  the two contols with the
>> > name were at the same level in the control hierarchy - but that is
>> > 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
>> > ambiguity, and there is also no guarantee of being (easily) able to
>> > 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
>> 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
>> 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
>> 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
>> very unlikely, obviously. As I said, I don't think there is any way
>> 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
>> even during a session? I haven't checked).
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>use-livecode mailing list
>use-livecode at
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:

More information about the Use-livecode mailing list