FILE OBJECT AND STRGET: TOO HARD FOR NEWBIES
- I believe that the File object and StrGet are quite fiddly to use, and I had to do some very subtle checks to make sure that what I was doing was both correct and safe. Hence I would suggest adding a version of at least one of the simple functions presented here:
file set text/empty/get encoding/force read with specific encoding - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=47084
JEE_FileEmpty
JEE_FileGetEncoding
JEE_FileSetText (aka JEE_FileWrite, this can also achieve what JEE_FileEmpty does)
(I also include JEE_FileReadForce there)
- I would steer newbies clear of FileOpen. FileOpen with 'w' ERASES/EMPTIES the file's contents, just by its presence. Even though it warns that it 'overwrites' the data in the documentation, people might assume that it can only overwrite the data, once you *do* something, not simply by opening the file. Also, people can be unclear what 'overwrites' means, in this context it means 'empties' rather than write over. I.e. it reduces the file size to 0, if you simply open it in write mode and close it.
- Another confusing thing about File objects, is that you can set the encoding using File.Encoding, but AFAIK you have to explicitly add the BOM as a string, Chr(0xFEFF), using oFile.Write, to give the file a BOM.
- I would say that the File object should be thought of as something for experts only, for dealing with binary data, or for dealing with a large file without loading it entirely into memory. IMO the simpler functionality should be available via functions, i.e. 2 or 3 of the 3 functions I outlined above.
- StrGet is fiddly for example, if you want to apply it to binary data, you can't specify to read from the first n bytes of data, only the maximum number of characters to return. Thus if you try to read binary data as though it were UTF-8, using StrGet, you can go beyond the data, unless it reaches a null byte. To apply StrGet to the binary data of a file, I'm not sure if there is an easy way to ensure that it will reach a null character, unless you create a buffer, with a null character at the end, and copy the data there. E.g. a buffer that is equal to the size of the file plus 3 null bytes to handle ANSI/UTF-8/UTF-16.
SET THE TEXT OF AN EXISTING FILE
- This example shows how fiddly it can be to set the text of an existing file:
Help with %A_BACKSPACE% - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 60#p210560
The whole thing could be done with one function. Cf. ControlGetText/ControlSetText, or setting the text of a variable, or FileRead, which are easy.
- Note: it's fiddly to make sure that you change the text but don't change the encoding of the file.
- Also, I don't like the use of FileDelete, because users should want to preserve the creation date of the file. (I know that the system sometimes tries to make assumptions to assist programs that delete a file, when they intend to empty it, prior to appending content.)
- Note: users need to know that writing to UTF-8 or UTF-16 without the BOM, means that AutoHotkey can't then automatically identify that file as UTF-8 or UTF-16, it assumes that they are ANSI. I would always encourage people to use the BOM.
