Strange contents of long name

[Richard Gaskin]

Peter Haworth wrote:

 > Here's a recipe.
 >
 > Create a couple of fields on a card.  Open the inspector for one of
 > them and set the name to empty - when you tab out, it will have a
 > name in the form "field id xxxx", which is LC's way of indicating
 > that the name is blank.  Leave the name for the other field as "Field"
 >
 > Group the fields.  The group will be created with an empty name so
 > open its inspector  and give it a real name.
 >
 > Select the field with a the name "Field" and in the message box "put
 > the long name of selobj()"  you'll see it contains the group name.
 >
 > Select the field that has the empty name and do the same thing in the
 > message box.  The long name will contain the ID of the group, not the
 > name.

I flagged this as a bug back in '05:
<http://quality.runrev.com/show_bug.cgi?id=2629>

There I wrote (for the benefit of those not in the Dev program):

    When you query the long name of a control, if its name is empty you
    get its long ID.  That the control's ID should be used is
    appropriate, but notice that the card also appears in ID form, even
    if it has a name.

    I believe this is a bug, as we should expect to get the card name
    when querying the long name of an object, and only get its ID when
    the card name is empty.


To which Mark Waddingham replied:

    Indeed this is the current behaviour which is actually wrong
    according to the documentation:

    "If an object's name is empty, getting its name yields its ID
    property instead. In this case, the abbreviated ID form is always
    reported, regardless of what form of the name property you request."

    So, I agree from a consistency point of view that the 'long name'
    should return what constitutes each objects 'name' all the way up
    the chain (named controls => name, unnamed controls => abbrev. id).

    In the end whether to 'fix' this comes down to a backwards
    compatibility issue:  according to the docs, the long name in the
    specified case should only be relied upon to have three words and
    so we *could* with this in mind change what comes after; but on
    the flip-side it is perfectly feasible that stacks are currently
    relying on the uniqueness that the long name property is currently
    giving for unnamed controls (arguably, incorrectly)...


Later in the comments there I offered to take the flak for any backward 
compatibility complaints, and Mark Waddingham's last comment seemed to 
suggest he would be adding it to the to-do list.

Apparently this has not happened, so I've taken the liberty of bumping 
the report to add a link to this thread.  We'll see what happens.

In the meantime, it may be helpful to know if anyone here has scripts 
which are dependent on the current behavior, as backward compatibility 
seems to be the only concern at this point.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys