[Kst] [Bug 120827] Command line option -f fails for some asciifiles

Ted Kisner tskisner.public at gmail.com
Fri Jan 27 20:17:19 CET 2006

On Friday 27 January 2006 09:11, Brisset, Nicolas wrote:
| I can't imagine how this could have worked
| differently since the introduction of ASCII configurations a few months
| back...

ok, looking at the code, the last time I used kst for this stuff must have 
been before the current ASCII datasource was in use.  I guess the previous 
method of reading ascii files was dumb enough to trust the user and "do the 
right thing".

As Barth mentioned, we now need the data source to be smart enough to 
determine the number of fields ahead of the user requesting the starting 
line.  I'm not sure what the right method is.

Perhaps we could have the datasource keep it's current behaviour (return the 
fields at line 0), but with these changes:

1.  add another parameter to the fieldListFor function that specifies the 
starting line.

2.  if readField is called with a field that is not in the fieldList, do an 
additional call to fieldListFor with the current start frame to detect any 
changes in the field list.  If the field is still not valid, the return an 
error like normal.

So this has the following benefits:

1.  small code changes.

2.  The available fields are only re-scanned if the requested field is 
invalid.  In situations with a constant number of columns, this never 

What do you all think?  Should I make these changes?  Are there any 
consequences I've missed?


More information about the Kst mailing list