OK, it's been very quiet lately, so I thought I'd roll up the few minor bug fixes that have accumulated and put out a minor fix release.
But then I thought, "every time a release goes out, then a small flurry of bug reports and suggestions come in."
So, if anyone has a nuisance bug not yet reported, a minor enhancement you'd like, or a "wouldn't it be nice if ..." type item, then please respond to this thread with your ideas and comments and I'll try and look after them before this next release.
The bug where temp files get written with corrupted file names still exists. It would be nice it this were fixed, because it creates random file names in a directory, and that could accidently destroy data if the corrupted name just happened to match a good file. I have seen this as recently as two months ago.
Me: I just went and tried SPFLite and watched the Temp folder. I had to spend quite a while cleaning my Temp folder just to get it down to a dull roar so I could see what my testing was doing.
Files are created in there by SPFLite, and cleaned up when SPFLite terminates. It all seems to work just fine. Now if SPFLite crashes or is cancelled these file could be left behind, but they ARE in the Temp folder where it seems that oodles of other apps leave all kinds of trash behind. But in any case, the next SPFLite execution will actually check the Temp folder for any left-behind files and clean them up.
Leaving files behind in Temp is not good practice, but should not cause any problems other than wasted space.
** I don't see any evidence of corrupted file names, could you explain what you're seeing? And why you believe they belong to SPFLite? All temp SPFLite filenames are of the format UND*.TMP
** There is no possibility the temp file names SPFLite uses would collide with any other file names. SPFLite requests the filename from a Windows API which guarantees the name will be unique. So collisions and/or files being destroyed are just not possible.
The other day I was creating a file (boot.bin - a bootstrap program) and had to edit using HEX ON. I got really wierd stuff whilst changing the top row (high order nibble) to x'0' especailly when auto-scrolling to the right. I do not really know how to describe it exvept perhaps that nothing seemed to line up - ASCII v Hex representation.
This may be something to do with my machine - Win 10 SPFLite v8.2.5179 as when I tried to recreaate the error today by creating a new file nothing displayed - no ticks in cc1-6 no hex, no ascii. I had left hex on when I had finished the previous session. Anyway, I then cancelled and SPFLite bombed - but I cannot find the crash report