From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
06-05-2012 09:12 AM - edited 06-05-2012 09:13 AM
Exactly as I said above: 😄
"Could it be it is an indicator instead of a control? (this distinction is easily lost when overusing local variables)"
So not only does the program suffer from localitis and sequenceitis, it also requires edit mode for part of the use. Aarghhhh!
06-05-2012 09:12 AM - edited 06-05-2012 09:13 AM
Yet another argument against the overuse of local variables.
Edit: Altenbach beat me to it.
06-05-2012 12:03 PM
And I understand what the OP is going through. Dealing with old inherited code. I'm sure he knows by now that sequences and locals are not good answers. But refactoring the code is probably not an option at this point either.
Rob
06-05-2012 12:49 PM
@Robert Cole wrote:
And I understand what the OP is going through. Dealing with old inherited code. I'm sure he knows by now that sequences and locals are not good answers. But refactoring the code is probably not an option at this point either.
Rob
It depends. How long does this code need to exist and what is the likelihood it will need to be modified. If the answer to the second is very likely it may very well be worth the investiment to refactor it and get more maintainable code as a result. Later you may find adding new features will only take a few hours or days as opposed to weeks with the old code. Not to mention the chance for bugs will be much greater when modifying the house of cards like the old code.