ja...
I've done speed tests only one small files (less than 1M) and on those, passing any control to kixtart instead of the whole file makes the delays with Idispatch grow huge.
what comes to data type, not sure what you mean by actually anything you said before.
we both know that kixtart can basically handle only longs and strings and arrays of those.
having the ability to write or read anything else is waste as it can't be used anyways.
as an addition, kixtart already has text-I/O routines, so only binary (hence the dll) is lacking.
thus, writing strings with the dll is not on option.
well, could do binaryString but as already realized, it takes seconds to read even small files.
so, all I'm left with is bytes.
and taking account kixtart only handles longs and strings, I can export and import the data only with these vartypes.
again, we know that kixtart has trouble with, say chr(0) and afaik, with everything that goes above 256.
so, strings as export is not an option.
conclusion, all that is left is long.
to import, I have already enabled all that kixtart can handle, bytes as strings (one char long) or longs.
both input and output on fileIO is done with INT (fwrite,fread) and trunslated to I4 or from I4 just for kix.
that about covers it.
so, asking where does the additional data-types come into action?
and, if you access the files as series of bytes, how you can limit your access in any way?
heck, it's bytes, no matter what vartype you see externally.
_________________________
!download
KiXnet
