Exact name reference

[mhsu]

Livecode's normal behavior for referencing controls is to reference the first control (in layer order) that matches. Is there a way (besides using control id) to force livecode to do an exact path match of a reference?

Example:
I have a group "abc". Inside group "abc", I have two controls: group "def" and graphic "myGraphic". Inside of group "def", I have another graphic, also named "myGraphic".

If I want to refer to the graphic "myGraphic" that is directly inside group "abc", how can I do that?
Normally, I'd write something like:

Code: Select all

put the backgroundcolor of graphic "myGraphic" of group "abc"

However, this runs into the issue that there are two graphics named "myGraphic" inside of group "abc". Livecode will return whichever one is first in layer order, which in this case, is the one that is a child of group "def" which is in turn a child of group "abc". Is there a way to tell livecode - I want to get the control with long name exactly matching? ie I don't want a control that has an extra group in the middle?

The reason I need this is because I am trying to programatically create controls, which might be nested inside of themselves. It would be really nice to refer to the direct child controls of a specified group. For now, the only workaround I have is to set a custom property that keeps the id of each child control when the group is first created. Then I have to reference my direct controls using:

Code: Select all

// At creation time, before putting anything inside my subgroup:
set the uControlX of me to the id of control "x" of me
...
//To later refer to the control "x" of me, and not control "x" of group "y" of me
put the backgroundcolor of control id (the uControlX of me) of me

I would love to say something like:

Code: Select all

put the backgroundcolor of graphic "myGraphic" of group "abc" exact

Where "exact" would mean "only look at graphic "myGraphic" that are direct children of "abc".

[dunbarx]

Hi.

Apart from a purely theoretical exercise in finding ways to ferret out one or another from a number of similarly named controls, why put yourself through all that? Assign unique names to unique controls. Those that share certain attributes can be made into "families", say, field "x1", field "x2", field "x3"...

In other words, your question ought never need to be asked; it is untoward to have to deal with such a situation. It can only bring grief, and will always be difficult to manage.

Controls can be referenced by number, ID, and name. Each has their benefits. I use names, and to a lesser extent number, almost exclusively.

But perhaps you have your reasons? If so, tell me.

Craig

[RCozens]

... I am trying to programatically create controls, which might be nested inside of themselves. It would be really nice to refer to the direct child controls of a specified group. For now, the only workaround I have is to set a custom property that keeps the id of each child control when the group is first created.

Hello,

I suggest you continue to reference controls by id. Is an exact name reference required in the handlers of the controls you are creating, or is this only an issue during their creation? If it is the latter, you can delete the custom properties of the controls once they are created. If it is the former, while the scripting is less straightforward, once it is working reference by id will avoid the potential pitfalls posed by having multiple controls with the same name in the same stack.

Cheers!

[richmond62]

there are two graphics named "myGraphic" inside of group "abc"

Ouch!

Couldn't you ensure that graphics of what we might choose to call the 'myGraphic' class
aren't named sequentially in order of creation: 'myGraphic1', 'myGraphic2'. 'myGraphic3' and so on?

In this way there would be very little risk of things getting confused and you could refer to
those graphics by name.

[RCozens]

If I want to refer to the graphic "myGraphic" that is directly inside group "abc", how can I do that?

Here is another option. I don't know if it's better or worse depending on your specific needs.

Instead of saving the graphic id as a custom property, one could place a handler in the group script:

Code: Select all

on graphicBackgroundColor
    return (the backgroundColor of graphic "myGraphic")
end graphicBackgroundColor

Then one could code:

Code: Select all

send "graphicBackgroundColor to group "abc"
set the backgroundColor of [some control] to the result

Cheers!

[RCozens]

If the above does not work try:

Code: Select all

on graphicBackgroundColor
    return (the backgroundColor of graphic "myGraphic") of me
end graphicBackgroundColor

[quote/]

Sorry, try:

Code: Select all

on graphicBackgroundColor
    return (the backgroundColor of graphic "myGraphic" of me)
end graphicBackgroundColor

[Bernard]

Livecode's normal behavior for referencing controls is to reference the first control (in layer order) that matches. Is there a way (besides using control id) to force livecode to do an exact path match of a reference?

Example:
I have a group "abc". Inside group "abc", I have two controls: group "def" and graphic "myGraphic". Inside of group "def", I have another graphic, also named "myGraphic".

If I want to refer to the graphic "myGraphic" that is directly inside group "abc", how can I do that?
Normally, I'd write something like:

Code: Select all

put the backgroundcolor of graphic "myGraphic" of group "abc"

However, this runs into the issue that there are two graphics named "myGraphic" inside of group "abc". Livecode will return whichever one is first in layer order, which in this case, is the one that is a child of group "def" which is in turn a child of group "abc". Is there a way to tell livecode - I want to get the control with long name exactly matching? ie I don't want a control that has an extra group in the middle?

The reason I need this is because I am trying to programatically create controls...

I have been unable to login to the Forum for weeks. But what you're trying to do isn't difficult at all. Years ago I worked on a tool that created apps from a specification.

Use this to get an object reference (long name) to address ambiguously-named objects in groups of groups.

Code: Select all

function objInGroup pObjName pGrpName
  repeat with i = 1 to the number of controls
    put the long name of control i & cr after tList
  end repeat
  put quote into qq
  filter tList with merge("* [[qq & pObjName & qq]] of group [[qq & pGrpName & qq]] *")
  return tList -- should contain only 1 line, the long name of pObjName in group pGrpName OR empty if no such object in group
end objInGroup

put the backgroundColor of objInGroup("a","g1")

I make it a rule to pass objects around with vars using either tObjectLongName or tObjectLongID. Not only does it provide disambiguation, but this lends itself into manipulation of lists of them using the filter command.

[mhsu]

Thanks everyone for the suggestions. I tend to agree that the ideal case would be to name everything uniquely. I think the case where this wouldn't be possible is somewhat theoretical. My idea would be something like: I have a set of grouped controls, which functions as a tabbed group. All the code is prewritten as part of this group, with no knowledge of what is inside of each tab. Ideally, I'd like to make simple references to the "x" of me within the tab group's script, but given that I don't know what might be inside each tab, I would need to make sure all names are unique.

I think Bernard's script works perfectly for my needs -- I hadn't thought of parsing long names in that way. Thanks!