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 try: -- pControl is the long id of a control function unamedControl pControl return (name of pControl = abbrev id of pControl) end unamedControl Regards, Scott Rossi Creative Director Tactile Media, UX Design On 1/16/13 4:14 PM, "Peter Haworth" <p...@lcsql.com> 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 >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 <gcan...@gmail.com> wrote: > >> On Wed, Jan 16, 2013 at 3:36 PM, Alex Tweedly <a...@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@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
