A scathing review based on my experience upgrading from labview 7.1 to 8.2.

[Roy_F]

---

@billings11 wrote:

... Travis, I know I deserve a thorough response.  But you are probably the 10th NI representative I've brought all these things up with in the past several weeks and I still don't have any response on any of them... 

---

I want to echo Travis' gratitude for the well written feedback you have provided. I can not explain why the other NI representatives have not responded to your feedback, but I can assure you that Travis will respond and he will respond well. Travis is a LabVIEW Product Support Engineer and we consider upgrade problems to be very serious. I can not guarantee you will like all you hear (the comment color being a case in point), but his responses will be thorough and timely.

Roy Faltesek
Senior Group Manager
LabVIEW R&D, Sustaining

[tst]

---

@Roy F wrote:

I can not guarantee you will like all you hear (the comment color being a case in point)

---

So are you saying that my explanation was correct?

If so, what is the reasoning behind it (other than the one Altenbach brought up)? Why was it decided that people would not be able to change the default so that they can keep working as they used to?

[billings11]

Roy,

NI has no business trying to standardize comment color by making it inconvenient to have any background other than yellow with black trim.  Functional standardization across industries is accomplished by providing a development environment that is adaptable enough to serve all those industries.  NI's responsibilty is to deliver a powerful, adaptable software language that crosses industry boundaries and satisfies developers' needs.  It is not NI's responsibility to force developers into changing commenting styles that have been in place for years.  I understand it is nice to try to make things as standardized as possible, but it should be limited to functional standardization.  This has nothing to do with function.  This is not VHS vs. Betamax or Blueray vs. HD-DVD as one comment suggested.  We are talking about default comment colors.  All you are doing is annoying your developers.  Why not take away custom controls too while we are at it, so everyone's GUI's look exactly the same too.  Will coloring while loops a slight pigment be considered a violation of NI law as well?  Tell us now so I can plan never to upgrade again.  The point is its really none of NI's business if I want to have blue comments.  Its a dumb idea for them to try to make it their business.  And I mean really, black and yellow?  I'd like to see white backgrounds with no trim as an option, but I guess thats too much to ask.

I would love to see a real, intelligent, thoughtful explanation of a single one of the problems I have listed - especially the free-text default color, but most importantly the resample waveform thing.  It is just so negligent I can't believe it.  You broke every single application in the world that uses the default value.  I wonder how many developers are out there right now with no idea their code is broken, running experiments or tests with the wrong waveforms without knowing it.

Visual Studio .net is free now, and we have already planned to do all the important code in C on our next project.  That includes all the data manipulation and waveform generation.  We have no choice, because we only want to write this code once.  This upgrade was just too painful.  The only thing we are still going to use labview for is the GUI's.  Sure it would be a lot easier to do the whole thing in labview.  But next year if I upgrade labview I know C will still resample and subset waveforms the same as always.  Once we get used to it hopefully we can cut labview out entirely.  We'll keep an old version around for lab experiments, but not for real development.  Maybe this isn't all NI's fault.  They are trying to make money here, after all.  Maybe I am running into the limitations of what labview is.  Its a proprietary tool that can change at the whim of the proprietor, not a software language (as much as I'd like it to be one.)

tst,

You can actually still change the default free-text colors, just not the yellow background.  If you hit CTRL-0 (zero) and pick the dialog font and click the color to change it.  When you have it the color you want check the "diagram default" box.  Now you have changed the free text default color, but the stupid yellow background with black trim can't be changed!  They disconnected the "transparent name labels" option from free-text labels.  Dumb. 

[billings11]

tst,

The other difference is now in 7.X and beyond won't save that default dialog color in the ini file, so you have to re-select it each time you open labview.

[tst]

Ah, I see now. You're talking only about the font color.

Is the solution in the LAVA thread I linked to not working for setting the free text to have a transparent background and no outline?

For what it's worth, in the current beta there is again a checkbox in the options dialog for changing this, so that you can automatically have a transparent background and no outline.

[wd8ivl]

Billings11,

I have to chime in here.

While I haven't run across all of the issues you have, in making the transition from LV7.0 to LV8.2, I did notice a bunch of things that got changed...

Like the Tools Palette being moved from Window to View...like the color of the error wire...like the graphics on some of the VI's have changed...like pushing the abort button on the wiring diagram stops the vi but puts you back on the front panel. 

And with all of this, they still can't figure out how to allow you to lock the wires to the grid!

Maybe someone should revive the "10 Things I Hate About Labview" before the next NI Week...

My comment to NI (and I've said it lots of times to the local reps) "IF IT AIN'T BROKE - DON'T FIX IT!"

Mike

[tst]

---

@tst wrote:

For what it's worth, in the current beta there is again a checkbox in the options dialog for changing this, so that you can automatically have a transparent background and no outline.

---

But the font color does not persist after a restart.

Did you try copying the INI key created by LV 7 into the 8.x INI file?

[tst]

And thinking about this some more, this sounds like a bug (or at least unwanted behaviour) - when you set something as default (even if the interface for setting it is not particularly good), you expect it to stay that way.

[billings11]

tst,

You are right, the solution in that forum transparentBDFreeLabels=True dpes work!  Thanks!

At least I can get around those stupid yellow labels.  I flat refuse to use those.  But I am still trying to figure out how to make the color save to the ini file somehow.  I am looking through the 6.1 ini now.

[Travis_M.]

Hello everyone,

Again, thank you to billings11 and other LabVIEW enthusiasts for taking the time to give us such detailed feedback.  I find it upsetting that you have had such difficulties upgrading your application to a newer version of LabVIEW, and the broader issue of ease of upgrading is one that we are aware of and are continuously working on.  I had planned to address all these concerns at once, but I think more frequent interaction is being requested, and if you wish, a conference phone call with you (billings11) will be set up as soon as we can (please bear with us while we get that scheduled).
I’ll just address the analysis VI change for now since it was at the top of the list.  In general we have a policy at to make all code as compatible as possible, and we certainly would NEVER consciously break code, or intentionally make upgrading painful.  For obvious reasons, we really do try our hardest to improve LabVIEW between versions, and sometimes to fix a problem, you introduce another.  How many Software Engineers can claim that they’ve never introduced a bug when fixing a bug?  This problem came about when we changed the default value of that control to fix another problem, and our normal process of integrating mutation code didn’t happen.  We did document it, which hopefully made life at a least a little easier, but I respect your opinion that this was not good enough.  You are correct; we should have introduced code to mutate your code from 7.x automatically so that users would have not encountered this problem.  Please understand that we have processes in place to make sure things like this don’t happen, and that these problems are rare.

 
To keep things as constructive as possible, we would like to know if you are still affected by this problem.  Do your VIs still need to be converted?  If so, we would like to help however we can.  If not, please accept our apologies that we did not mutate your old code.  The final loose-end is that CAR 4A4B8RXC has been filed on the issue, and in future LabVIEW versions, we are looking at mutating 7.x code automatically so that this doesn't occur.

Thanks again, I'll continue to post here to address the other issues-