Strange contents of long name

Scott Rossi scott at tactilemedia.com
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
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
>






More information about the Use-livecode mailing list