Custom Query

Listview subentry request

I think the list-view control can even be better if you could add a sub-entry to it, like in a tree-view control... which can be expended and collapsed...

I.E.: Item1 | Subitem1 | Subitem2 Item2 | Subitem1 | Subitem2

SubEntry1| Subitem1

Item3 | Subitem1 | Subitem2

and so on...

Not really a bug, but I couldn't think of where else to put these. Issues in the help file.

1) "16 = Force binary mode (See Remarks)." is on the FileOpen page, but there's nothing about binary mode in the remarks.

There is on the pages for FileRead and FileWrite, but they should probably be on the FileOpen page too which actually has the byte mode flag.

2) The FileRead page doesn't mention anything about where the read will start, doesn't imply that it will use the current 'position' or otherwise.

3) In the help file, the FileOpen flags 32, 64 and 128 say that "Reading does not override existing BOM." which doesn't make any sense. Reading doesn't overwrite anything anyway. Pretty sure it should say writing, and should probably specify the second write flag (as the first is append and shouldn't be anywhere near the BOM anyway).

4) This one's a bug. I'm not sure whether the FileOpen 128 flag (versus the 256) is supposed to keep the write position from moving lower than 3, or cause write flag 2 to have an automatic protected BOM inserted in front of it, but it seems to do neither.

FileOpen sets the initial position to 3 for a UTF-8 file that has a BOM when you use a 128 flag, a 256 flag, or no flag (auto detection). In all cases, FileSetPos(, 0, 0) sets that position to 0, which is before the BOM. I *think* that's probably intentional, using that same constant regardless of the presence of a BOM.

If you FileOpen a UTF-8 .txt that has a BOM with the 130 flag (128+2), and then FileWrite, the BOM stays. But if you call FileSetPos(, 0, 0) and then FileWrite, the BOM disappears, meaning the 128 flag is not doing anything at all here. It doesn't restrict the write position in write mode 2 and it doesn't prefix a BOM (if you return to the beginning of the file).

If you FileSetPos(, >2, 0) then flag 130 prefixes the BOM and then pads with spaces to get to the right position before beginning the write.

None of this behavior is mentioned or detailed in the help file, so I can't tell what's intended. "Append a text/data to the end of a previously opened file." is the description of FileWrite, but it seems to be a lie if you FileOpened with write flag 2 instead of 1. And all that's said of 2 is "2 = Write mode (erase previous contents)" (under FileOpen), which implies to me that it writes from the beginning of the file and position doesn't matter, not a) pads to the current position with spaces first, and b) starts that padding with a(n overwriteable) BOM instead of spaces if flag 128 is included/detected AND the position is >2. Even with the 128 flag, if the position isn't >2, part of the BOM is overwritten. If you use position 1, you get 'ïText'.. the first UTF-8 BOM byte with the other two overwritten.

3.3.7.21(beta) 3.3.6.1

Any reference to $oExcel.ActiveWorkbook.Sheets.Count after creating the Excel object with _ExcelBookAttach() seems to error. These are the five functions with that reference:

_ExcelBookOpen _ExcelSheetDelete _ExcelSheetList _ExcelSheetActivate _ExcelSheetMove

And this is the error:

C:\Program Files\AutoIt3\Include\Excel.au3 (1063) : ==> The requested action with this object has failed.:
Local $iTemp = $oExcel.ActiveWorkbook.Sheets.Count
Local $iTemp = $oExcel.ActiveWorkbook^ ERROR

References to $oExcel.ActiveWorkbook.Sheets() work fine. It's the ones without parenthesis that break. They also all work fine if the object is created with _ExcelBookOpen() instead of _ExcelBookAttach().