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
pmb...@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@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
