I have an Interface that’s working well, letting me easily switch between different Containers that I use as WebPage layouts, thanks to very patient help from users in this forum (https://forum.xojo.com/31073-dynamically-change-property-type/p1#p254221). Because a lot of Methods accessed Controls before that Interface was created, it was suggested that I rename my existing Controls (e.g., TextField1 renamed to innerTextField1) and then have Methods in the Interface and Containers match the original Control names (e.g., Method TextField1 in the Container returns innerTextField1, and there’s a corresponding uncoded Method TextField1 in the Interface).
This works fine. And I understand why it was suggested I rename my original Controls: if TextField1 is referenced in a Method somewhere , the compiler might get confused as to which object is being referenced (the Control TextField1 or the Method TextField1).
But I notice that if a do a global Search and Replace on all instances of “inner”, so that all the Controls are renamed back to their original names (e.g., innerTextField1 is renamed TextField1), everything works fine. It appears that having a Control and a Method share the same name in a Container doesn’t confuse the compiler. I assume it doesn’t get confused by this reference because
A Control, as far as I can tell, is always referenced in a Method with a dot property, like .Text or .Name.
The Interface Method TextField1, for instance, will execute the Container Method TextField1, ignoring the Control TextField1, because it’s looking for a Method not a Control.
Am I correct in assuming I can have a Control and a Method share a name and not worry about the compiler not being able to determine which object is being called by a Method? It sure makes things easier to revert back to the original names of my Controls.But I don’t want to do anything that will bite me later if Xojo stops allowing this.
Sure, you can have many TextField1 on Container Controls, windows, as well as one or several TextField1 method. The compiler will know which one to pick if your code is right.
But it is way better to have different, descriptive names, for controls as well as methods. For instance I generally use a prefix such as Tf followed by a description of what it does, like TfName, TfAddress, and so on. The more descriptive the method, the better. For instance sub turnUppercase(byref Tf as Textfield) is way more descriptive than TextField1(TextField).
Note that TECHNICALLY you don’t have to have descriptive names. But ERGONOMICALLY, meaning for your own comfort, you will appreciate having done that when you come back later to your code. While you are in the development process everything makes sense, but what about in two years, or like me with Barcode Wizard eleven years later when I decided to place in the MAS an app I had written back in 2002 ? If I had done like you describe, I would have been completely lost.
If you really dig into it, you will find that some of the references are using the method, while others are using the control directly. That could create problems later if you add additional functionality to the methods. Sometimes that functionality would be used, and sometimes not, leading to hard to find bugs in your code. I would recommend not overloading names that way unless you fully understand what you’re doing.
Thanks, Michel and Tim. I have elected to keep the names of the Container Controls different from their corresponding Container and Interface Methods. Though, for now, it’s easier to change them so those names are the same, I fear I could have debugging issues in the future if I do that.
I am just getting to grips with containers and have several in the app I am working on. Container2 and Container3 - for example - will never both be present on the same window but both have an edit field for entering the name of a database table. Is there a downside to calling the edit field dbTable in both containers or should I call them Container2dbTable and Container3dbTable? Similarly, I have a couple of identical methods in the two containers which I would prefer to give the same name to.
I started putting the database code in a database module but found it a bit convoluted when I wanted to supply a database method with data from a listbox in a container.
There should be no problem with an editfield in one container having the same name as an editfield in another container. Even if they were on the same window at the same time.