Strange contents of long name

[Peter Haworth]

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 <scott at 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" <pete at 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 <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
> >>
> >_______________________________________________
> >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
> >
>
>
>
> _______________________________________________
> 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
>