Leaderboard

For a GUI I'm doing, I find myself wishing for something like which notoriously is not possible per element, as array element properties (e.g. disabled) apply to all elements. On the other hand, the array container is soo convenient because it's growable and indexable at runtime. Can someone share an idea of implementation? I've been thinking: programmatical rewrite of the content of the "uneditable" elements which are changed (bad, it gives the user the impression that content could be written into); placement of a fixed maximal number of replicas of the element cluster on FP, and visibility of those needed (will become inconvenient for large numbers); array of clusters with subpanels (no goer). Actually my customer is suggesting something like which would be easily realizable (input field is copied to result on Value Change for editable elements, blanked for uneditable), but I find it a little overbloated, if it has to be extended to more cluster fields. Moreover both Enter and Focus off cause Value Change, unless they are trapped and treated...

I can't say why, but I know there were lots of requests for us to build this, so some users definitely use it. Regarding a competitor for NI... I would welcome it. The problem is the sheer expense. I've contemplated building different graphical languages just as prototypes for people to play with. I can leverage all sorts of rendering tools, formats, etc, but an edit environment is expensive compared to a text editor. Every graphical language needs a largely unique environment. I'm lucky ... I can hack the existing LabVIEW environment to simulate syntax, but doing this from scratch would be way more than I could undertake alone, at least with the tools I've seen. I think it would take corporate level investment to do one with graphics at the quality users expect today. I doubt LabVIEW could even get off the ground if attempted for the first time today.

For what it is worth, I can't use Git. Even for simple submits, I do it infrequently enough that I pretty much always screw it up. I've thrown away changes I wanted to keep. I've merged branches the wrong way. At this point, I use Git by writing what I want in English and emailing a friend for the commands to do it. I recognize its power. I recognize that it is the only SCC system with certain key features. I would still rather use anything else.

Are you talking about the NI Service Updater thing? Yeah I have never used that to update any PC, and never will. I have a hard time trying to convince it to stop bothering me. I don't upgrade software, drivers, operating systems or anything in the PC ecosystem unless there is a good reason. It just adds new risk changing the environment from what you've been using. So unless you are in an academic environment, or just playing around and not making production level applications, why would I ever want you updating a thing?

We've stuck with SVN, it's suited me just fine and I love it. At one point I understood the DVCS systems, but never saw the need for it in my workflow and haven't bothered to switch over. Because all the cool kids are doing it doesn't fly for me. Now excuse me while I cry, because my SVN is being pried from my hands in favor of...urgh. Don't make me say it. Rational Team Concert. It sort of works, so there's that.

As I said, they may be working for your situation. But plugins tend to be a problem sooner or later. You can't usually just include your own VIs as the vi.lib directory is not present in an application. So you need the entire hierarchy but then you can't use any standard LabVIEW function that exists or uses a VI inside an lvlib or lvclass. With many of the LabVIEW VI libraries being turned into lvlibs recently, this is a serious problem.