Duplicate Control Names - Don't understand

[Traxgeek]

Hi,

I'm sure this must have been covered a hundred+ times before but...
I thought I understood then... Anyways, please excuse the re-covering of this topic but having read lots I remain confused...

Control names. I understand a control name is just a friendly (intuitive) way for me to reference a control that, in reality, has a unique ID assigned to it by LC. I get that. I guess LC then maps my friendly control name to its unique ID before undertaking any action on or with it... Makes sense to me...

Often though it's handy / useful to duplicate a control name. Naturally, I 'm not suggesting one could make many controls all called the same name at the same 'level' on a specific card and then hope to select any specific one of them with such a generic name/approach BUT... (maybe this is where my confusion comes from) whilst I fully understand LC is NOT VisualBasic / .NET I come from that background and in those environments whilst one is NOT allowed to create a duplicate control name (trying to, simply fires up a 'you can't do that warning') it IS possible to have controls duplicated WITHIN different groups...

i.e. A control called 'ControlA' can be duplicated (and keep it's name) should the copy of the original then reside in a different group of controls to the new/duplicated control. One would then reference each one by it's extended name : 'ControlA' is different to 'ControlA' of group "GroupB'

Not knowing any better I continued along this vein (I won't bore you with the why and wherefore's but it made/makes sense to do so) and my LC apps have, generally, behaved themselves...

From time-to-time though, like today, I note LC to be 'unhappy' with me doing this... which then makes me unhappy...

So, my question is this :

What is the definitive rule for duplicating control names (given that each duplicate resides within a different group) ?
Don't do it ? - But this can lead to some really messy code
You can do it as long as each duplicate is 'contained' within a different group (bearing in mind you'd need to include the group name with the control name in order to reference that particular control) ?

Like I say, I've read a quite a bit and simply find my self (1) confused and (2) seeing it work 8 or 9 times out of 10 but then throwing a hissy fit the 10th time...
I should also add that (to date) duplicating a control (like the background for a button) on many buttons on the same card appears to have no adverse effect AS LONG AS the duplicated control has no script individual/unique action/script associated with it... in this case these controls would simply be acting as the 'background' to a button...

Thoughts please ?
A million thanks...

[Klaus]

Hi Trax,

well, do whatever you like, but don't compalin afterwards!

I would never use controls with the same name on one card, that IS asking for trouble.
Since you are used to not being able to do that, why not keep this behavior and simply avoid duplicate names?


Best

Klaus

[Traxgeek]

Hi Klaus,

It's precisely because I AM used to doing it this way (as long as the duplicate control name does NOT exist at the same 'level' as the originating control / exists within a different group to the originating control) !!

I'm simply wondering what the 'RULE' is with LC. LC MUST have a rule - it's this RULE I was after - regardless of what one developer does in relation to another...

I do appreciate your response... I'm simply frustrated at not finding a clear RULE and then (because I don't understand the rule) have LC sometimes (most times) work flawlessly and other times have a hissy fit !

I'm sure LC is not as forgetful as me and doesn't simply choose to do it 'this way' with 'this control' and 'that way' with 'that control'... so there HAS TO BE a rule but I'm simply wondering what it is... I would have thought that control "ControlA' would be recognised as being a different control to control 'ControlA' of group 'GroupA'... maybe not... I don't know and hence my question...

Maybe I shouldn't bother - just DON't duplicate - simpler - but harder (which seems wasteful to me) in many cases...

Thanks all the same...

[Klaus]

Sorry, no idea about a "rule" in LC...

[FourthWorld]

I'm simply wondering what the 'RULE' is with LC. LC MUST have a rule - it's this RULE I was after - regardless of what one developer does in relation to another...

If there's a general rule at all it may be that most good programming languages are comprised of three primary elements: a gun, a bullet, and a map to our foot.

After all, if they're not flexible enough to let us do things we later regret, they're probably not flexible enough to let us do the things we actually need to do.

LiveCode is no exception to this rule.

As as for naming rules, the challenge is that difference scenarios will require different strategies. LiveCode is very flexible, so we can get a lot of very interesting work done very quickly, but sometimes we need to think about the details of what we want to do in advance (or be willing to spend a little time later cleaning up after ourselves <g>).

There are times when it's very handy to have objects with the same name. For example, in many of my layouts I name label fields with "lbl", and then when I run through a loop to collect data from the group they're in I can just skip over any field with that name.

If you need more objects with similar but distinct names than could efficiently be done manually, you can write a script to create them for you, e.g.:

Code: Select all

on mouseUp
   MakeButtons 20
end mouseUp


on MakeButtons pNumberOfButtons
   lock screen
   lock messages
   create group "ButtonCollection"
   set the vscrollbar of it to true
   set the rect of it to 20,20,200,500
   set the lockLoc of it to true
   put the left of it + 4 into tX
   put the top of it + 4 into tY
   repeat with i = 1 to pNumberOfButtons
      create button ("MyButton"& i) in grp "ButtonCollection"
      set the lockloc of it to true
      set the topleft of it to tX, tY
      add the height of it + 4 to tY
   end repeat
   set the vscroll of grp "ButtonCollection" to 0
   unlock screen
   unlock messages
end MakeButtons

[newtronsols]

Rule: Might be worth reading about childControlIDs, altid etc

You may become more confused after, like me.

[dunbarx]

Hi.

What Klaus said. Know that the "owner" of each of those commonly named controls will distinguish them, since each can be referenced to the group that contains it.

Often I will make lots of label fields, and not bother to name them, since they never interact with any real work I am doing. This comes home to roost now and then, perhaps when you might want to change some property of that entire "class" of control. So it is always good practice to name everything, even if, in the above example, the names were "label1, label2, etc."

Craig Newman

[Traxgeek]

OK thanks Klaus.

Sorry (in advance) to bang on about this - but I know you'll be able to help me... so, please bear with me, I'm not trying to be pedantic, just understand... (and I'm crap at explaining exactly what I mean in a concise manner)... here goes...

In .NET the control 'ControlA' is completely different to the control 'ControlA' of group "GroupA'. I know we're not talking about .NET BUT I come from there... as I understand it (although I haven't written it for yonks) it's the same with Java... (I stand ready to be corrected though)...


My point is this :

I have created a roll-your-own, slide down, button that's cross platform. Said button consists os a field displaying the current selection, an image with an up/down arrow on it, and an empty background field that covers any area behind any transparent parts of the image and a final field that holds the options for that button. 3 fields and 1 image. I group these into a group and name said group something like 'grpBtnChoose'. My code goes into the group script.

So, say I now want to have a second button, named 'grpBtnSelect'

Do I need to rename ALL the controls in the group ? In .NET all the controls in all the grouped buttons could have the same name because I'm referencing them via the group name first / I inculde the group in the button path...

If I wish to access a control in a group I MUST do so by including the 'path' to (the group that contains) the button...

With LC I have continued along this vein... but by the sounds of it I'm wrong (although 99% of the time this seems to have worked perfectly - hence my now having reams and reams of code to check through). I don't want to change my methodology unnecessarily although I'm (obviously) willing to do so IF it is necessary...

So if I now understand correctly, because all controls should be uniquely named, one does NOT need to include the group name that the control resides in to reference that control...
which means that LC considers that control 'controlA' is the same as control 'ControlA' of group "GroupA' ?

Does that make sense.. If so then the way 'around' this is to uniquely name each control and not bother referencing a control via it's group... ?

Would that be accurate ? Like I say, I have a lot of code that seems to work (most of the time) and I don't want to go changing it on a whim...

Thanks for your patience, understanding and your time. I do appreciate it.

Regards
TRAX

[bn]

Hi Newtronsols,

you made part of the rule: do not use same name control within a group

if Livecode encounters same-name controls it addresses the control with the lowest layer number.
But the id is always different. So the name is only part of the story, the id is how LC can decide between same-name controls.

There are times you can not avoid/want not avoid having same-name controls

e.g. you make a group of controls and want to use the group more than once on a card.
The trick is to always include "the owner" when addressing controls within that group.
If addressing a field "fData" from within a group for example a button always code
send mouseUp to field "fData" of the owner of me. This will avoid confusion as to which field "fData" to address.
And you can and should give the outermost group of your widget different names without interfering with anything.
Basically this also applies to nested groups within a group. Just have in mind who is the owner of the control. You can also address control x of the owner of the owner. ETC. This even lets you find out if the control is outside of a group, (the owner is then the card) or the chain of owners (if the name of the owner starts with group)

Of course not knowing what happened in your special case this is only one example how to leverage the same-name of a control in different groups from within that group. To address same-name control from outside the group you already mentioned to add "of group xyz"

I hope this does not add to confusion but helps to understand

Kind regards
Bernd

[FourthWorld]

In .NET all the controls in all the grouped buttons could have the same name because I'm referencing them via the group name first / I inculde the group in the button path...

You can get the same result in LiveCode by just doing the same thing, including a reference to the group as part of the reference to the object within it.

As Bernd noted, just calling an object by its name alone will cause LiveCode to look for the first one in the layering order. I would imagine .NET works similarly, in that if incomplete object references are allowed at all its engine needs to do a little guesswork about which instance you mean, sometimes guessing correctly and sometimes perhaps not.

So applying the same solution you use in .NET to LiveCode, just turn something like this:

Code: Select all

get the long id of btn "SomeButton"

...into:

Code: Select all

get the long id of btn "SomeButton" of group "MyOtherGroup"

The same principle applies to cards and stacks as well: you can address any object in any container, even if another object has the same name, but just being specific about which one you're after by including its container.

[Traxgeek]

Hi Bernd.

Gotcha. Thanks a million. EXACTLY THE SAME as with other languages I've played with...
So I just need to go look at why (occasionally) LC doesn't do quite as I expect it to with nested controls...
Hmmm... That'll be down to me

Once again, thanks all. Not only have you helped clear this up for me but I'm sure it will be useful clarification for others to come !

Much obliged.

[FourthWorld]

So I just need to go look at why (occasionally) LC doesn't do quite as I expect it to with nested controls...

Feel free to post your code and I'll bet we can find a good solution for you quickly.

[bn]

Hi TraxGeek,

sorry I misnamed you in my previous post. See, I can't even tell the difference between Traxgeek and Newtronsol

I made up a little script that should select the controls of same name on the same level, i.e. where a possible problem in addressing them could arise.
Of course there are numerous ways of addressing same-name controls ambiguously. But just to clear one side of the problem and lets suppose you did address them as correctly as possible by name and e.g. group etc.

put this into a button and make a field named (sic) "fRes" or change the code to output to the message box.

Code: Select all

on mouseUp
   repeat with i = 1 to the number of controls
      put the name of control i & comma & i & comma & the long name of control i & return after tCollect
   end repeat
   delete last char of tCollect -- a return
   sort tCollect by item 3 of each -- the long name
   sort tCollect by item 1 of each -- the name
   put "" into tOldName
   put "" into tOldLongName
   put "" into tOldLine
   repeat for each line aLine in tCollect
      if item 1 of aLine = tOldName AND item 3 of aLine = tOldLongName then 
         set the selected of control item 2 of aLine to true
         set the selected of control item 2 of tOldLine to true
      end if
      put item 1 of aLine into tOldName
      put item 3 of aLine into tOldLongName
      put aLine into tOldLine
   end repeat
   put tCollect into field "fRes"
end mouseUp

Kind regards
Bernd

[SparkOut]

just to add another little nugget of information when it comes to identifying with granularity in parent/child scripts:

"of me" and "of this ..." will help resolve local controls, as well as being aware of "the owner" and "the target".

[Traxgeek]

Hi

No worries Bernd - I answer to pretty much anything Especially when you guys are giving up your valuable time to help me !!!

I got it all now. It's (pretty much) identical to my recent years of coding with VB, .NET and PCSoft...
Somehow I got my knickers in a twist over naming conventions and then the forum just added confusion to my already befuddled brain cells... Light has dawned - thanks to you guys...

Can't thank you all enough chaps - much obliged.

As an aside, I created a couple of apps (to help me manage a property letting business we run) over the last 12 months but was (for various reasons) unable to try them on my Android devices. Upon finally being able to do so, I noted various 'issues' with checkbox, drop-down menu and option controls (to name but a few) when deployed to mobile which I then spent time 'rolling my own controls' for, hence the duplicated control names (i.e. in a group of checkboxes or options...) which led me on to my problems and subsequent question here...

I must admit I'm actually beginning to have a bit of fun with LC rather than fighting it - refreshing...

Again, Thanks a million guys. Appreciated.