FileGetString
This reference collection includes Vector documentation reproduced with permission. Snippets may require configuration-specific symbols and are not all standalone programs. Sources and validation limits.
Contract
long fileGetString(char buff[], long buffsize, dword fileHandle);
The reader stops at a line boundary or after reading buffsize - 1 characters. When it encounters the end of a line, the returned string contains a line feed. When the buffer cannot hold the line, a later call continues with characters that did not fit. The documented return is 1 for success and 0 for error; it is not the number of characters read.
The dynamic File class also provides GetString. Do not mix a class instance and a numeric handle in the same lifecycle merely because the method names look alike.
Pick a reader according to the evidence you need
| Reader | Line-feed handling | Implication |
|---|---|---|
| fileGetString | Retains the line feed when a boundary is encountered | Can preserve useful evidence while assembling a record |
| fileGetStringSZ | Does not include a line feed in the buffer | Convenient for validated short lines, but absence of LF cannot establish whether a long record was complete |
Neither variant promises that every successful call returns a whole logical record when the line is too long. A CSV field containing an embedded newline introduces a separate logical-record problem: these string readers are not CSV parsers.
Counterexample: a valid number can be a truncated number
With a capacity of 8, at most 7 characters are read on a call. A physical line containing 123456789 can therefore begin with a successful chunk 1234567. Parsing that chunk immediately as a timestamp silently changes the input; the next chunk is not an independent timestamp either.
Set a documented maximum record length. Accumulate chunks only within that bound, and publish a record to the numeric parser only after its boundary has been established. If the limit is exceeded, reject the operation or discard through the full offending line under a documented policy; do not accept a suffix as the next record. Test the exact-capacity boundary as well as an obviously oversized line.
Failed reads must not turn yesterday's data into today's data
Clear or invalidate the application-level current-record state before attempting a read, and only parse after a successful result. Do not assume a failed call clears the destination buffer. A loop that parses outside its success branch can count the last timestamp again when reading stops.
The available extracted reference does not establish a distinct EOF-versus-I/O-error result. Therefore, label an unexplained stop as read termination, not automatically as clean EOF. If import completeness matters, compare expected counts or use a version-documented diagnostic mechanism. Do not label a partially imported dataset complete simply because the loop ended. The source's description of accepted line-ending forms is also incomplete; test LF and CRLF fixtures in the installed version instead of assuming their byte-level treatment.
The file I/O validation walkthrough specifies empty lines, unterminated final records and overflow cases. This is source-based analysis and a proposed test method, not a claim that the examples were run in CANoe. See sources and limits.