I am busy writing a desktop application which reads downloaded info files every 2 minutes. Because these files are coming from the internet it can happen that something goes wrong (communication, xfer error or what) that the file does have zero bytes.
I have a check on such files to leave zero byte files aside and not use them:
f = GetFolderItem(aFile)
catch err as NilObjectException
Logs(“AnalyzeFileEQ”,“Error: “+cStr(err)+” occurred at “+d.ShortDate+”/”+d.LongTime+" for file: "+aFile)
and a second one incase the err does not occur:
If f <> Nil And f.Exists then
if f.Length = 0 then
NoInfos = true
NoInfos = False
NoInfoTeller = 0
textInput = TextInputStream.Open(f)
textInput.Encoding = Encodings.MacRoman
//analyze the inputfile and store values in the apropriate variables till the end of file
While Not textInput.EOF
normally this responds good, but I have that phenomenon that after a day the files will not be overwritten anymore and the date/time stamp defers for hours. The only way to release the “locked” file is to quit the application and start it again. Than always the file can be removed or overwritten.
I tried to use TextinputStream.Close () and TextinputStream.Close (f), but that all resulted in the error: Static reference to instance method: call this on an instance of class TextInputStream.
Well I deal with text files in this manner, maybe it’s helpful for your purpose. TargetFile is your FolderItem, FileContent is the content you can run checks against. Dont forget to check Encodings first.
dim FileContent as String
dim SourceStream as TextInputStream
if TargetFile <> Nil then
SourceStream = TextInputStream.Open(TargetFile)
if SourceStream <> Nil then
FileContent = SourceStream.ReadAll
TargetFile = nil
SourceStream = nil
Thank you Tomas for your solution. I adjusted all parts where files are read with the try…catch…finally…end try entries and now all files are released. When file contents was not received from the internet, the empty file can be manually removed or will be automatically overwritten with the new file of the next run. Just as expected.