>Faststring.dll won't store its strings in VFP. You'll have to use FTRANSFORM(), FLEFT(), FRIGHT(), or FSUB() to return a string usable in VFP.

I get that, but unfortunately I don't think that helps when retrieving individual values out because API calls (or FLL calls) have their own overhead in VFP. Have you done any performance comparison walking through a string with SUBSTR() compared to FSUBSTR()?

Transforms are fine and that was in fact what my original parser did to cheat and get at least reasonable performance, but it gets problematic with a truly generic parser where anything can be in a string. Transforms ended up having tons and tons of edge cases that in the end required further transformations etc. that would slow things down. For a solid parser one literally needs to stream content character by character which is what is unfortunately slow in VFP.

Curious to see if what you've built here might address that although I'm not holding my breath due to the overhead of the API calls that may end up killing any native performance gains. That was my experience at least with the DECLARE DLL interface - maybe FLL is better there.

In the end the better, much faster and way more reliable solution for me was to a use a known library in .NET to handle the parsing and taking the result data and turning it into Fox data. Plus it's a known solid solution that handles all sorts of edge cases, but it was a lot of work to switch from the old parsing to that. The upside is though that I have not run into anything that doesn't deserialize with this parser which is considerably better than what I had before. Building reliable parsers is hard... :-)

Anyway - I'd be interested to see some benchmark comparisons between the native FoxPro functions and your replacements although I think Fox is pretty damn good with almost everything except SUBSTR(). I can't think of other scenarios where I've needed something to provide faster string support.

+++ Rick ---