05-01-2012 02:12 PM
What if your “Strings” array is empty or “start index (0)” is >= “Strings” array size, you have catch me if you can loop.
To avoid inf loop, you should check for empty array first or modify with Conditional For Loop or modify the condition check “i = (size -1)” to “i >= (size -1)” and rename and relocate the VI to your project dir.
-lvABC
05-02-2012 07:07 AM
Darin.K shared this one a little over a year ago.
"In this case there is a bonus lesson about using vi.lib VIs, beware of bugs. This VI contains a doozy, Kudo opportunity for the spotter."
I'm still on 8.6 so I don't know if Darren's proposed fix got into LV2011 or not...
05-02-2012 09:48 AM - edited 05-02-2012 09:48 AM
PhillipBrooks wrote:
Darin.K shared this one a little over a year ago.
"In this case there is a bonus lesson about using vi.lib VIs, beware of bugs. This VI contains a doozy, Kudo opportunity for the spotter."
I'm still on 8.6 so I don't know if Darren's proposed fix got into LV2011 or not...
Ooooops didn't check that post, and it has not been fix in LV2011 SP1.
Sorry, -lvABC
05-02-2012 09:57 AM
@lvABC wrote:
...and it has not been fix in LV2011 SP1.
It's fixed in my copy. Maybe that was fixed with the LV2011 SP1 f1 patch.
05-02-2012 10:04 AM
@crossrulz wrote:
@lvABC wrote:
...and it has not been fix in LV2011 SP1.It's fixed in my copy. Maybe that was fixed with the LV2011 SP1 f1 patch.
Yes, crossrulz it is fixed in LV2011 SP1.
I’m sorry about that, I had LV2010 SP1 opened and I was replying the post and when I originally posted.
Again sorry, lvABC
05-22-2012 03:31 PM
UPDATE:
NI SCOPE SFP fails to launch? Yes under unusual conditions and there apparently has been a work-around for some time
Today I found the reciently released LabVIEW RTE 8.6.1 f5 patch incorporates the fix!
01-03-2013 04:03 PM
Thanks to Chris Roebuck for finding the following weird behavior.
It's possible to have an "empty" array that's not "really empty". Take the following snippet:
As expected, both arrays return a TRUE for the "Empty Array?" primitive, yet the first one returns a non-zero array for the dimensions:
If you're not aware of this behavior, it could lead to unexpected results, when, for instance, autoindexing the arrays:
01-04-2013 06:01 AM
01-04-2013 10:54 AM
@jcarmody wrote:
This looks like a candidate for the CLAD exam.
Originally from http://www.codinghorror.com/blog/2010/02/welcome-back-comments.html
I hope not! I would never pass to become a CLAD! And thanks to altenbach for pointing me to this thread that further discusses the topic.
And for a new bit of minutiae while were's on the zero-dimension topic... (and to follow the rules of this thread )
Be mindful of "Equal?" primitive equality comparisons. As demonstrated in the snippet below, surprisingly a 0x0 array is "equal" to a 0xN array yet not equal to a Nx0 array:
Again, these minutiae can manifest themselves as esoteric "bugs" and unintended behaviors, especially when relying on auto-indexing -- just know these behaviors are correct, thought not necessarily intuitive, so be mindful!
01-04-2013 11:44 AM
In my not-so humble opinion, 0x0 = 0xN is a bug (for compare aggregates). They would have to be completely insane to not.. <quick LV coding>
</quick LV coding>
Holy Cr@p! There is no pre-flight checking of Array dimensions for Equals? in compare aggregates mode! Why am I yelling?! If I take a 2D array, chop its last row and compare to the original array it checks all elements and then says I guess it is not equal when it hits the extra row. At least it does short-circuit when it hits the first nonequal element.