I am writing a live updated file in RTF format for a project. The idea is that you can open the file and look at it even though the program may still be writing to it so I try to keep the file flushed to the disk and with the proper RTF format so that it can be opened at any time. This also protects the data in there against crashes as youll always know that the last thing written might have been complicit in the problem. If I left the file open and just let the system manage it Id lose that and also the RTF structure would not be correct so you couldnt open the file while it was open in the other app.
In order to do that I have to write the RTF end bracket after I finish writing, then flush the file. When I want to append to it again I have to back up the position a character or 2 to be able to overwrite that end bracket and then add another one at the end of the next line.
This works fine until the log file reaches a dozen meg in size or so and at that point I get the spinning beach ball for several seconds every time I try to open and write to the file. I think that opening the file and backing the position of the stream up by a character breaks whatever automatic buffering the system does or whatever buffering that Xojo is doing behind the scenes.
I am considering options for dealing with this, including just telling people that if you want to view the file you have to cut the log and let it start writing to a fresh file, but this is a change from years of doing it the other way. My first thought was to move the file management out to a thread and do the file manipulations in that. However threads in xojo apps are cooperative and it occurs to me that calling file operations are not likely to yield and so will probably block the program just as effectively as they are now.
Do long winded file operations like that operate threaded? Or is this a waste of time?