Custom Query (3926 matches)
Results (406 - 408 of 3926)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #3580 | Fixed | FileSetAttrib - Crash on ROOT folders. | ||
| Description |
FileSetAttrib("C:\DirWhichDoesNotExist\SubDirWhichDoesNotExist", "+H", 1) MsgBox(32, "WORK", "WORK") ;You will see this MsgBox FileSetAttrib("C:\DirWhichDoesNotExist", "+H", 1) MsgBox(32, "WORK", "WORK") ;You will NOT see this MsgBox - The script crashed. |
|||
| #3579 | Fixed | Clarification of Help for DllStructGetData(): never returns an array | ||
| Description |
jchd has invited me to take a crack at improving the help for this function: see https://www.autoitscript.com/forum/topic/191600-does-dllstructgetdata-return-an-array-for-short-array/#comment-1374426 Here is my suggestion. Yes, I know it is long, but I don't see a way to make it both clear and short. Here goes. For Parameters > index, change to "[optional or required] For elements that are in array format, specifies sub-element to retrieve. Applies only to elements that are in certain variable-type formats: see Remarks." For Remarks, change to: "This function never returns an array. When an element is in char[n] or wchar[n] format, the data returned is a string. When an element is in byte[n] format, the data returned is of binary type. For any other element that is in array format, specifying index causes the function to return one scalar value. index specifies which. In this case, index is required. It is 1-based, so enter 1 for the first sub-element. For elements in char[n], wchar[n] or byte[n] format, index is optional. Specifying it causes one character or byte to be retrieved. n is 1-based. For any element that is not in an array format, index should not be specified. For numeric formats (including byte format), Autoit always converts the value as specified by the element to the nearest Autoit type (e.g. for an element in byte format, an Int32 is returned; for float, a Double is returned). |
|||
| #3577 | No Bug | _FileWriteToLine strips @crlf off last line for some files | ||
| Description |
compared the .log to the .log_after files and notice the fail case has the last @crlf removed. #include <File.au3> Local $sSourceLine = "227487744 148299776 11.1.6749897" Local $sTargetFilename = "fail.log" Local $sFilenameTmp = $sTargetFilename & "_after" FileCopy($sTargetFilename,$sFilenameTmp,$FC_OVERWRITE) _FileWriteToLine($sFilenameTmp,2,$sSourceLine) Local $sTargetFilename = "pass.log" Local $sFilenameTmp = $sTargetFilename & "_after" FileCopy($sTargetFilename,$sFilenameTmp,$FC_OVERWRITE) _FileWriteToLine($sFilenameTmp,2,$sSourceLine) |
|||
