When importing ASCII data using tab/auto delimiter spaces in header are treated as delimiters resulting in more columns than data.
this was fixed recently. Can you please compile the current code from our git-repository and try it again?
Created attachment 111524 [details] Test data (header is 28/29 rows long) The current git code seems to not be able to break up tab delimited data at all. I have attached a file I am working with (hybrid ini+csv).
Looking at AsciiFilterPrivate::prepareDeviceToRead, the column names are always taken to be the first row of the file rather than the last row of the header. Would the latter behavior make more sense? It fits my uses better but I don't know if there was a reason behind why it was implemented this way.
(In reply to Justin from comment #3) > Looking at AsciiFilterPrivate::prepareDeviceToRead, the column names are > always taken to be the first row of the file rather than the last row of the > header. Would the latter behavior make more sense? It fits my uses better > but I don't know if there was a reason behind why it was implemented this > way. Yes, we need to use the first row where we start to read from and not the very first line in the file. There is another problem with your file. After the header is removed to overcome the first problem, we identify the columns STD_Current and STD_Resistance as integer columns and not as "numeric" columns and you end up with 0 values after the import instead of nan's. We'll fix these issues very soon.
Git commit 2d5cf861d10eb90c1e117b12d1d57bf4666527b6 by Alexander Semke. Committed on 25/03/2018 at 09:15. Pushed by asemke into branch 'master'. [ASCII import] in case we're asked to skip some lines, use the first non-skipped line to determine the column modes intead of using the very first row in the file. FIXED-IN: 2.5 M +36 -26 src/backend/datasources/filters/AsciiFilter.cpp https://commits.kde.org/labplot/2d5cf861d10eb90c1e117b12d1d57bf4666527b6
(In reply to Justin from comment #3) > Looking at AsciiFilterPrivate::prepareDeviceToRead, the column names are > always taken to be the first row of the file rather than the last row of the > header. Would the latter behavior make more sense? It fits my uses better > but I don't know if there was a reason behind why it was implemented this > way. I fixed this issue now. Can you please check it on your side? You need to start reading from line 29 in your file. You can use the preview tab to check whether the current settings will produce correct results (proper number of columns, their names and data types).
It works on my side perfectly! Thank you