LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bad explanation of [Mark after Read] of VI "Read Delimited Spreadsheet" from File palette

Solved!
Go to solution

Hello all,

 

today I came over the VI "Read delimited Spreadsheet" to make my programming life easy. There I stumbled over the output "mark after read (chars)", whose meaning I did not immediately understood, since I'm not a native english speaker. In the LabVIEW- Help there is written:

mark after read returns the character (byte) in the file following the last character read.

For me this sounds like, here is returned the character itself, which is following the last read character. But this leads me to two questions:

  1. Why is it of type I32, and not U8, which would be expected with the annotation "returns the character (byte)..."
  2. This information seems for some tokening- operations useful, but this task is so rare, that it seems strange in this High- Level- VI.

OK, in short, after diving into the hierarchy of this Polymorphic VI (I used the DBL- instance), it turned out to be the file mark position after succeeded read operation, which is only almost the same as described. At least for me...

And on the way down I found a far better explanation for this terminal in the description of "Read File+ (string)":

 

mark after read is the location of the file mark after the read; it points to the character in the file following the last character read.

 

IMHO this explanation is far less misleading and should be used for the terminal.

My long text seems a bit pointing, but I like saving time with informative programming help (especially if being a beginner, struggling with so many things besides just programming an algorithm).

 

P.S. I'm counting a bit on our experienced forum knights to give a hint to NI R&D to change this terminal help text, since I don't know where to report this.

 

Greets, Dave
0 Kudos
Message 1 of 5
(951 Views)
Solution
Accepted by topic author daveTW

Blow horns, sound fanfare, cheer at the sound of my trusty steed as my Knighthood rises to assist you!

 

Go back to the problematic help file entry that you want NI to hear your valuable feedback about.  Then simply click the "Submit Feedback on this topic" link.


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 5
(930 Views)

I agree that the language is a bit too sparse and you should report it.

 

Of course it does not make sense to output the last byte, because you already know that. Basically it is used to in symmetry with the start position (where the help is better!) if you need to read the file in chunks instead of all at once. If you feed it in a shift register, you know where to start reading next time.

 

altenbach_0-1658588285732.png

 

A more serious problem IMHO is the fact that files can of course be larger than the range of I32 and file positions are actually I64. (If you dig inside, you'll eventually see a coercion dot where it is wired to a terminal that expects I64).

 

Of course nobody in his right mind would use formatted files exceeding ~2GB (But I am sure many will try!!!). Once the datasets get so big, there are better options than to convert to a limited set of ASCII characters (0..9, period, tab, etc.) to make a lossy and expensive description of the data. 😄

 

0 Kudos
Message 3 of 5
(909 Views)

I did as you suggested. Funny thing: I can only navigate throu the German- localized part of the NI site, so it took me a while to find the right Help page. The translated name is correct, but funny. And: the german-translated description is correct and isn't written in the misleading way. 😀

But anyway I'm not willing to switch the language (nor the programming language).

 

@altenbach: thank you for your answer

Greets, Dave
0 Kudos
Message 4 of 5
(865 Views)

Hi Dave, 

 

This is Michel from the Language Services Team at NI.  We are the group in charge of the translation of that help content you see on ni.com (as well as anything else in the product). I did read your post on the forum and I was also forwarded your feedback on the help topic you submitted through the feedback link.

I'm going to attempt to reply to your comment in its globality.

1. I think you are stating that you would have prefered if the link from the English LV software to the help on ni.com had taken you to the English page.  But because you are a German customer, most likely located in Germany, you were taken to the German help page.  That is by design indeed, as we serve the content on ni.com depending on your ni.com locale.  By default, that locale will be set automatically based on IP Geolocation, so "German/Germany" for you.  But you can override this by clicking at the bottom of the page on your existing locale (you will see a German flag), then you will be taken to our Global Gateway and you can pick North America>>United States (English).  A few years ago, this was at the top of the page on our web site, but very few customers needed to use the language selector, so it was relocated at the bottom of the page during the latest redesign of the web site.

Babel_0-1659033101480.png

 



2. You are also stating that even though you would have prefered to see English, the German translation was actually less confusing than the English original source text.  I love to hear that.  It means that whoever translated it into German put the time to think about the real meaning, possibly asked a developer and came up with a better text than English. 

3.  Your main point is that the English description for "mark after read" is confusing, and I believe you are correct about that.  "Mark after read" seems to be the "offset in the file after the last character read".  I will follow up with our dev team to make sure that a ticket is filed to improve this in future version of the API help.

 

Please keep the feedback coming.  We love to hear directly from customers!   If you have any specific feedback on translation, mention the words "translation" and "localization" in your post, so that our Web team can be sure to route it to us.

Message 5 of 5
(816 Views)