Jump to content

LabVIEW 2011 SP1 f2 Patch Released


asbo

Recommended Posts

Thanks for the heads up.

"Searching for text in an enum that resides within a typedef will cause changes to the values within the enum" is particularily disturbing to me as almost all my enums are typedef-ed and I search some of them fairly often.

Link to comment

I think that's the one that most people are likely to run into. "Array data changes unexpectedly when passed through a case structure in a timed loop" could be pretty nasty too, but I don't often use timed loops.

I know that each CAR and bug fix probably has a huge amount of information about it. Things like under what conditions it is reproducible, and what work arounds are available. But I can't help but think that NI could have been a little more descriptive with their one sentence summary of this bug fix.

Also I thought it was odd that a patch was released for a version of LabVIEW which is not the latest, and by that I mean 2012 which was released a few weeks ago.

Link to comment
I thought it was odd that a patch was released for a version of LabVIEW which is not the latest, and by that I mean 2012 which was released a few weeks ago.

Some of us have to fight to be allowed to upgrade. I went from LV8.6.1 to LV11 after SP1 was released, and that was only by using the, "It's easier to ask forgiveness than it is to get permission" principle. A fine Navy tradition. :-)

So I'm happy to see NI sends out patches to "legacy" LV versions. (Of course I'd be happier if it didn't need them!)

Link to comment
  • 11 months later...
Thanks for the heads up.

"Searching for text in an enum that resides within a typedef will cause changes to the values within the enum" is particularily disturbing to me as almost all my enums are typedef-ed and I search some of them fairly often.

 

Found this old thread as I was searching for any new patches for LV 2011 SP1.

 

Before submitting the corresponding CAR, this one destroyed my code base.  Basically searching for your type-def'd enum value would either change or in case of arrays possibly empty the array each time you pressed Ctrl-G to go to the next instance.  What made this so insidious was when you arrived at the next search instance there was no way to tell that the array of values (imagine array of 5 states/commands) had been altered or emptied.  The bug was unpredictible, undetectable, and did *not* register in the undo stack.  So the next time you saved, the code was hosed.  Upon discovery, I had to check the logic of every state transition.

 

For some reason it took months for NI to roll out the patch.  So, there could be sections of code written in LV 2011 SP1 out there that have been affected but not yet discovered because you have to know to even go looking for the changes.  By far the worst bug I've experienced.  Maybe like coding pre-undo only LabVIEW makes random changes?

 

LV 2011 SP1 crashes regularly.  Is LV 2012 stable?  Conditional loop indexing looks great.

Link to comment
LV 2011 SP1 crashes regularly.  Is LV 2012 stable?  Conditional loop indexing looks great.

 

Surf your way to here. Somewhere around post #35 the thread wanders off onto the topic of the stability of various versions.  Everyone seems ot have adiferent opinion.

 

I had nothing but trouble with LV11.  LV12 SP1 works fine for me.  YMMV... 

 

(and yes, conditional loop indexing is great!)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.