Erroneous output with the String to 1D Array

[JKSH]

Hi all,

 

I first filed some bug reports at SourceForge, before realizing that the bug tracker there has been quiet for a year. Is this the preferred place to file reports?

 

Anyway, the two bugs are:

• String to 1D Array output is empty, if delimiter not found
• String to 1D Array doesn't recognize End of Line Constant
  

[todd]

Multiple lines in the string control end with Line Feed, not End of Line.

I agree that it's odd for ignore duplicates to provide different outputs.

Edited February 26, 2013 by todd

[JKSH]

Whoops, thanks for the info about Line Feed. Looks like the bug was between the keyboard and the chair.

[JKSH]

So, is the bug being tracked now? Is this forum the place to report them?

[JKSH]

Anybody?

[LogMAN]

SourceForge is the best starting point in addition to this forum. However the project has not developed much over the last couple of years (there are quite a lot bugs filed with no development for almost a year). You could fork the project for your own purposes and upload patches as you file bug reports or maybe become part of the team yourself (if one of the members would allow that).
The project might be dead, if none of the developers is interested in continuing it. In that case you could still fork the project, but there is little chance that anybody would benefit from patches (unless there is a way to fork a project and upload new versions to the VI Package Network...)

[MichaelBalzer]

I just ran in to this exact bug today (empty array output when no delimeters found). After a bit of testing, I'm confused as to what the expected output of the function is when Ignore Duplicate Delimiters is set. It certainly differs from my expectation!
 
Here are a few test strings I tried, with my expected output vs the actual output. All tests used comma as the delimiter, and have ignore duplicate delimiter set true.

 
Test Input          Expected Output          Actual Output
string1,string2     {"string1", "string2"}   {"string1", "string2"}
string1,,string2    {"string1", "string2"}   {"string1", "string2"}
string1             {"string1"}              {}
,string1            {"", "string1"}          {}
,,string1           {"", "string1"}          {}
string1,            {"string1", ""}          {"string1", ""}
string1,,           {"string1", ""}          {"string1", ""}
,string1,           {"", "string1", ""}      {"string1", ""}
,,string1,,         {"", "string1", ""}      {"string1", ""}
,                   {"", ""}                 {}
,,                  {"", ""}                 {}

[Rolf Kalbermatter]

Hi all,

 

I first filed some bug reports at SourceForge, before realizing that the bug tracker there has been quiet for a year. Is this the preferred place to file reports?

 

Anyway, the two bugs are:

• String to 1D Array output is empty, if delimiter not found
  
• String to 1D Array doesn't recognize End of Line Constant
  

 

The second is not really a bug. The End of Line constant on Windows is rn while when entering multiple lines in a LabVIEW string LabVIEW uses a single n only, except one explicitly enters the rn sequence. So the rn does not occur and therefore won't cause the string to be split in multiple elements.

 

Enclosed is a first attempt at fixing the "ignore duplicate delimiters?=TRUE" case.

String to 1D Array.vi

[MichaelBalzer]

Thanks for that. I did a quick test and it looks good. I'll report back if I find any problems. Any ETA of when the fix will see a release?

[JKSH]

Thanks, rolfk!

 

I tested your fix with Michael's test cases (with "ignore duplicate delimiters?" both TRUE and FALSE) -- they all produce the correct results.

 

Do you know when this will make it into the VIPM?

 

 

SourceForge is the best starting point in addition to this forum. However the project has not developed much over the last couple of years (there are quite a lot bugs filed with no development for almost a year). You could fork the project for your own purposes and upload patches as you file bug reports or maybe become part of the team yourself (if one of the members would allow that).
The project might be dead, if none of the developers is interested in continuing it. In that case you could still fork the project, but there is little chance that anybody would benefit from patches (unless there is a way to fork a project and upload new versions to the VI Package Network...)

 

I'd rather not fork, to avoid fragmentation. Do you know if there's a way for non-members to submit patches?

Edited May 26, 2014 by JKSH

[LogMAN]

I'd rather not fork, to avoid fragmentation. Do you know if there's a way for non-members to submit patches?

I've never done that, but I know there must be some option as you open a new ticket(might depend on the project). Some projects I follow provide a category called 'patches' to do such things.

It seems there has been movement in your bug reports a couple of days ago, so that's a good sign I would say.

Edited May 26, 2014 by LogMAN

[Rolf Kalbermatter]

I tested your fix with Michael's test cases (with "ignore duplicate delimiters?" both TRUE and FALSE) -- they all produce the correct results.

 

Do you know when this will make it into the VIPM?

 

Well, I can't make any promises. The function is in the sourceforge repository and as such available for download if you use SVN directly. Building packages is an entirely different beast, which I haven't done so far and also don't really know how to put it up on the VIPM accessible download locations.

 

It's also not very efficient to release a new package with every little change. There are other bug reports with other OpenG packages and also improvement requests, where there hasn't always been reached a broad agreement on how to solve it. Those likely would need to be consolidated and cleaned up as well, so there could be one single combined release of new OpenG packages.