Strange contents of long name

[Peter M. Brigham]

Here is a workaround, meanwhile, in the form of a virtual property "robustName":


getProp robustName
   ----  a virtual property, read only  ----
   -- getting the long name of a control can result in different values depending on
   -- (a) where the stack is stored on the user's disk and
   -- (b) which card is the currentcard when the property is fetched
   -- the robustName is consistent no matter what card is current
   -- and no matter which folder the user has stored the stack in;
   -- format: button "copyText" of bkgnd "fieldGp" of stack "substack1"
   --            of stack "myMainStack"
   -- the robustName can be used as a complete object reference,
   --    just like the long name
   
   -- requires q()
   
   put the long name of the target into tLongName
   replace " stack " with cr in tLongName
   put line -1 of tLongName into mainStackFileName
   if word 1 of mainStackFileName <> "stack" then
      put "stack " before mainStackFileName
   end if
   put the short name of mainStackFileName into mainStackName
   put q(mainStackName) into line -1 of tLongName
   replace cr with " stack " in tLongName
   replace " of " with cr in tLongName
   put lineoffset(cr & "card ", cr & tLongName) into cdLineNbr
   if cdLineNbr > 1 then delete line cdLineNbr of tLongName
   repeat with c = 1 to the number of lines of tLongName
      put line c to -1 of tLongName into ctrlName
      replace cr with " of " in ctrlName
      put the name of ctrlName into line c of tLongName
   end repeat
   replace cr with " of " in tLongName
   replace "group" with "bkgnd" in tLongName
   -- in case the group is not placed on the currentcard
   return tLongName
end robustName

function q str
   -- quote
   return quote & str & quote
end q

-- Peter

Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig


On Jan 16, 2013, at 9:41 AM, Richard Gaskin wrote:

> 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
> 
> 
> 
> _______________________________________________
> 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