Another LabVIEW 2019 case structure bug.

[Taylorh140]

There seems to be an issue with value entry for the case structure in 2019. I did this same range in 2018 without issue. 

To reproduce, open the VI. paste the range in the comment into the case structure.

wait for one second and LabVIEW crashes. 

Surprise! Let me know if its just my machine but I expect not.

[altenbach]

I see the same crash, so it's not just you.

(You say "another". Are there other bugs with the case structure?)

[wiebe@CARYA]

Could you also post an image? Saving to previous is obviously a bit weird, but I like to know what this is about.

[altenbach]

---

wiebe@CARYA wrote:
Could you also post an image? Saving to previous is obviously a bit weird, but I like to know what this is about.

---

[Taylorh140]

---

@altenbach wrote:

I see the same crash, so it's not just you.

(You say "another". Are there other bugs with the case structure?)

---

Another 🙂 I was referring to this post: 

Error Bug in Case structure LabVIEW 2019 

I was just running short on titles.

I also attached a previous version. 

[JICR]

Can we reproduce the bug on our machine without downloading your VI ?

What steps do I need to do?

Just in case 🙂

[Taylorh140]

So i created the vi from scratch multiple times. I think the killer is the range used.

I tried both the decimal version and the hexidecimal.

So basically all you need to do is create a U32 constant wire it to the selector terminal of a case structure, then write the following string into the case structure.

if hex radix:

7F800000..7FFFFFFF, FF800001..FFFFFFFE

or for decimal people:

2139095040..2147483647, 4286578689..4294967295

[RavensFan]

What if you try ranges that are slightly smaller?

Or just one range and not the other?

Or each half the size as you picked?

What if you wired a U64 constant to it?  or an I32?

If you can find a range that does work, and then a very similar range that doesn't work, maybe it'll find some clues.

[Yamaeda]

---

@RavensFan wrote:

What if you try ranges that are slightly smaller?

Or just one range and not the other?

Or each half the size as you picked?

What if you wired a U64 constant to it?  or an I32?

If you can find a range that does work, and then a very similar range that doesn't work, maybe it'll find some clues.

---

The 1st thing i notice is that the range is rewritten as ""..80000000, FF800001..FFFFFFFE""

I32 works

U64 works

I64 bombs

Splitting the ranges, didn't crash directly, but when i r-clicked to add a new case for the 2nd half it crashed. The case range is rewritten as above.

I think i've found it! Just writing ..7FFFFFFF crashes the U32 case. It gets rewritten as ..80000000 and something spins out of control!

Just having 7FFFFFFF and 80000000 works fine, it's the ".." that bugs out. In fact, if i write ..80000000 the case range changes to "0". I'm pretty sure those aren't equivalent ...

[TristanMayne]

I went ahead and validated this internally and have submitted bug #997753 in regard to this issue. It is worth noting that if I changed my data type from U32 to a DBL I was able to paste one of the two cases and then switch back to U32. However when I did both separated by commas and repeated he process LabVIEW ran but upon close gave me an internal warning message box.