I hope this is the right place to discuss about Designer’s improvements.
At the moment it is pretty much impossible to easily refactor tags, UDTs, Views, components’ names and scripts without messing up the project integrity. This is a feature which is a must in a modern IDE and it is necessary to avoid to break all the project’s references when simply renaming one of the aforementioned items: it really helps with the maintainability of our projects, mostly when there are many people working on them and keeping a common standard is not simple at all, so a bit of refactoring is necessary.
Moreover, I suppose the search feature should be improved as well, adding a way to show all the cross-references connected to the selected item, similarly to what we already have in programming tools such as TIA Portal from Siemens (sorry for naming a competitor).
I’ve also written a post on your Features and Ideas platform.
3 Likes
It’s as good as a place as ever to discuss these things.
Changing component names do come through in bindings FWIW and that is very helpful, and one of the reasons to use bindings when possible (not to mention generally speaking bindings seem to be faster than scripting doing the same thing).
Ignition is a double edge sword. It’s pretty opinionless and lets you do a lot, but that also means it will let you shoot yourself in the foot without stopping you.
My advice is in your scripts, get the value from the component into a variable and then use the variable. If you use event.source.getCompononent('SomeComponent').intValue 5 times in your script and then change your component name, you will need to change it 5 times in the script. But if you do
someIntValue = event.source.getCompononent('SomeComponent').intValue in the beginning and then only use someIntValue you only need to change the name in one place.
Another thing I try to do to help minimize this problem for myself is to think of the GUI as just a way to accumulate the parameters that end up in a function call. The less you have to reference components directly via event.source.getComponent('').someValue in your scripts, the better imo, and the less you would have to worry work you have to do when you change your component name. There’s other reasons for this of course as well, putting each capsule of business logic into its own function tends to make development and maintenance much easier in the long run.
FWIW I think IA has they are trying to make there search function work better for tags/a cross reference for tag calls etc.
1 Like
I recommend putting the component in a variable. Then you can reference any of its properties directly, and assign back. All with just the one name lookup.
3 Likes
They are working on improvements there, if memory serves, but it gets much more complex if any sort of indirect bindings are used.
1 Like
We actually use the approach of putting components in variables and then reusing them around our code (transforms, scripts and so on) and that is a great advice. Unfortunately this doesn’t prevent the fact that you are forced to go around your Views fixing references in case you want to refactor something. Bindings are great as well, but I assure you sometimes you have to work on projects written by people not so knowledgeable in good programming practises, and that’s when powerful refactoring features comes in handy.
It’s all about the approach of a modern IDE, in my humble opinion, and I don’t want to be a harsh critic: I just think time and good code maintenance are precious in our industry. Refactoring should be an easy-peasy action and should be totally automated by the programming environment.
Programmers are more than able to put a lot of bugs in their own code (
), so adding more of them 'cause the IDE is not helping us is not that great.
Yea that’s the advanced way to do it, I do that a lot with function calls for common operations (usually relating to Table/Power Table objects).