alex at tweedly.net
Mon May 1 07:09:53 EDT 2006
Mark Smith wrote:
> Todd, the only problems I see are 1) that you might miss ocurrences
> where the looked for string crosses chunk boundaries, and 2) You
> never close the file, and as I understand it from the docs, Rev will
> only close the file for you when the application quits.
> Scotts point about the size of chunk you grab is a good one, though
> the optimal size probably depends on how much memory your machine has.
> Anyway, I've done this, which is untested, but grabs larger chunks,
> searches the chunks, (rather than starting another read) and closes
> the file when it returns...
parallel evolution in action :-) Mark and I cam up with very similar
If you take the best parts of the two solutions, you'll get something
I forgot to close the file on exit (and in fact, I put in a spurious
"close file " that will never be reached.
Mark forgot to adjust his exit criterion for the case where the string
> function getPositionInBinaryFile pPath,pString,pStart,pOccurrence
> if pStart is empty then put 1 into pStart
> if pOccurrence is empty then put 1 into pOcurrence
> put length(pString) into strLen
> put 100000 into tSize
> put 0 into tFoundCount
> put 0 into tPos
> open file pPath for binary read
> read from file pPath at pStart for tSize
> put it into tChunk
> if tChunk is empty then
Won't happen - the last read will be a chunk of size strLen, so you
> close file pPath
> return 0
> end if
Alex Tweedly http://www.tweedly.net
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.5.1/327 - Release Date: 28/04/2006
More information about the Use-livecode