>
> What if, as it happened to me, the code was put together as a *huge*
> diagram where disconnected processes rely on the same front panel
> terminals ? Before version 6i there was no simple way to pack up "front
> panel sharing" code into separate sub-vi without having to go through a
> revised data model design. And even now, it seems that "remote" front
> panel access using references just cuts down data access speed.
>
It is true that property nodes are slower than terminals and locals, but
when used for UI purposes, it doesn't matter much. That is what they
are for. The bad things that people do to VIs, where they use UI
elements to pass data cannot be undone easily, well it usually isn't
that hard, but it
is tedious. Hiding ugly code in parallel single frame
structures or in a single parallel structure doesn't make it any
prettier or any easier to maintain.
It is something close to work, but I still believe that getting your
head around individual groups of code and giving them an appropriatly
named subVI, then moving to the next piece, is the best approach. Soon
you will likely find that the huge amount of code actually starts
shrinking as previously duplicated code is now shared via subVIs.
Initially leave all of the UI on the top level, and when you see items
that are repetitive, they can often be put in a loop or in a subVI and
use control references in a very good way.
I know that I'm preaching to the choir, but this is, in my opinion, the
only true way to clean up code. Plus it involves reading it to discover
what it does, and adding comments, which is actually the most important
thing to do before changing code.
Greg McKaskle
