gFileOpen fails with trailing whitespace at the end of the file.

[jordansread]

Datenum fails with multiple lines of empty space after the end of time series data.

[jordansread]

This may be resolved with my latest commits. Haven't tested.

[jordansread]

Nope, probably will still fail.

[lawinslow]

Really? gFileOpen uses the builtin datenum function, which seems to handle trailing spaces just fine.

datestr(datenum('2011-01-01 10:30 ','yyyy-mm-dd HH:MM')).

Do you have an example file which shows this phenomenon?

-Luke

[jordansread]

Actually, this is trailing empty lines. Poor wording on my part. e.g. a bunch of empty lines at the end of the files.

[lawinslow]

Ah, that's from the textscan function then. Could research alternatives if this represents a major issue....

[jordansread]

yeah, its just a fairly common error that people get but they don't really understand why. Creating a file in excel with some extra rows, convert to .wtr...error in LA. Low priority unless there is an easy fix.

[lawinslow]

Ah. Let me think about it and play around later.

Here is a question, some import methods are more liberal than textscan,
but they don't support as liberal an interpretation of "NaN" or "No
Data". What is more important? Diversity in forms of NA or this type of
error?

-Luke

On 2013-05-09 2:28 PM, Jordan S Read wrote:

yeah, its just a fairly common error that people get but they don't
really understand why. Creating a file in excel with some extra rows,
convert to .wtr...error in LA. Low priority unless there is an easy fix.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[jordansread]

I would say diversity in NaNs. Got to support NA, NaN and #VALUE!
agree?

[lawinslow]

Yeah, agreed. The solution needs to include both. Check.

On 2013-05-09 2:39 PM, Jordan S Read wrote:

I would say diversity in NaNs. Got to support NA, NaN and #VALUE!
agree?

—
Reply to this email directly or view it on GitHub
#4 (comment).

[jordansread]

Could wrap the easy/fast solution in a try/catch, and then do a line-by-line solution for the catch. Would be quite slow for big files, but better than not knowing why the error happened.