Thanks Scott. Yes, the loop checking the owner of the control is what I had in mind if the control name was empty so thanks for the unnamedControl function. Pete lcSQL Software <http://www.lcsql.com>
On Wed, Jan 16, 2013 at 4:33 PM, Scott Rossi <sc...@tactilemedia.com> wrote: > 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 > _______________________________________________ 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
