Jump to content

The one case bug


Wolfram

Recommended Posts

This behavior is present in LV 6.1 and still seems to be present in the newest version of LabVIEW.  I just filed a bug report with NI.

5804[/snapback]

Are you checking this bug list against the newest version of LabVIEW very extensivly? Would it be worth coordinating effort to get them all checked out? (I could help, but no sense duplicating effort)

Link to comment
Are you checking this bug list against the newest version of LabVIEW very extensivly?  Would it be worth coordinating effort to get them all checked out?  (I could help, but no sense duplicating effort)

5808[/snapback]

John, I have submitted a bug in the LabVIEW Wait beta.

Link to comment
I'm not sure if this is a bug.  It might just be a feature.  I recall a thread on info-labview on this a few years ago.  I think that when you are using string ranges, the upper limit is non-inclusive.

5846[/snapback]

It is a bug. The VI should be broken for "no case for some selector values".

Link to comment
I'm not sure if this is a bug.  It might just be a feature.  I recall a thread on info-labview on this a few years ago.  I think that when you are using string ranges, the upper limit is non-inclusive.

5846[/snapback]

It is a bug. The VI should be broken for "no case for some selector values".

5848[/snapback]

Jean-Pierre, I was referring to Wolfram's second bug posting, which has a string range frame and a default frame.

Link to comment
I'm not sure if this is a bug.  It might just be a feature.  I recall a thread on info-labview on this a few years ago.  I think that when you are using string ranges, the upper limit is non-inclusive.

5846[/snapback]

In case structures, you usually have to enter all included values, if the case structure handles integers. For me, this would be a strange feature, if strings are handled differently. So I think this is a bug.

Link to comment
In case structures, you usually have to enter all included values, if the case structure handles integers. For me, this would be a strange feature, if strings are handled differently. So I think this is a bug.

5893[/snapback]

It behaves differently for strings and numbers and I think this is the intended behavior.

The difference comes from the fact that strings are variable length objects. If the case for string range were inclusive, the range "a".."z" would match for all strings of any length beginning with "a" to "y" plus the lenght 1 string "z". To match all strings beginning with "a" to "z" you would need to set as the upper range the lexically largest string begining with "z" that is "z

Link to comment

I've come across a problem with a case structure as well. I have a case structure with a string wired to the selector input.

There are three cases:

"", "Idle"

"copy this state"

Default

When I try to right click the case structure and check "Case Insensitive Match," LabVIEW generates an error and shuts down. Deleting or modifying the cases seems to fix the problem, but this shouldn't happen.

I've attached the VI if anyone is interested in trying it. I'd be interested if it doesn't do the same thing on someone elses machine.

Download File:post-1591-1125504444.vi

Link to comment
  • 2 weeks later...
It's interesting how this bug only appears when you delete the TRUE case. If you remove the FALSE case and  leave only a TRUE then you get a broken VI which is the expected behavior.

5912[/snapback]

Also if you retype the False label, it becomes broken. (at least in LV 6.1)

Seems the error check is in there , just doesn't run right after deleting True.

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.