Custom Query
Results (175 - 177 of 3883)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2348 | Fixed | FileConstants.au3 doesn't have a constant for Option 8 for FileOpen | BrewManNH | |
| Description |
There's no constant inside the FileConstants file that corresponds to the FileOpen option 8, 8 = Create directory structure if it doesn't exist. These are all that exist inside the file. ; Indicates the mode to open a file Global Const $FO_READ = 0 ; Read mode Global Const $FO_APPEND = 1 ; Write mode (append) Global Const $FO_OVERWRITE = 2 ; Write mode (erase previous contents) Global Const $FO_BINARY = 16 ; Read/Write mode binary Global Const $FO_UNICODE = 32 ; Write mode Unicode UTF16-LE Global Const $FO_UTF16_LE = 32 ; Write mode Unicode UTF16-LE Global Const $FO_UTF16_BE = 64 ; Write mode Unicode UTF16-BE Global Const $FO_UTF8 = 128 ; Read/Write mode UTF8 with BOM Global Const $FO_UTF8_NOBOM = 256 ; Read/Write mode UTF8 with no BOM There are these though, but the first one is for the file open and save dialog functions, and the second is a file attribute, and their names wouldn't match up with the names for the other constants. Global Const $FD_PROMPTCREATENEW = 8 ; Prompt to create new file Global Const $FILE_ATTRIBUTE_OFFLINE = 0x00001000 |
|||
| #2350 | Fixed | Strange issue when using $SS_ETCHEDVERT and $SS_ETCHEDHORZ | Jon | BrewManNH |
| Description |
If you run the code below, you will see that $SS_ETCHEDVERT will create a static control 2 pixels wide on the left side of where the label control is supposed to be. If you minimize the window, and then restore the it, the appearance of the label has changed to appear to be using the $SS_ETCHEDFRAME style. Using the AU3Info tool I can see that the control's style doesn't change, just the appearance. If you uncomment any of the other lines that use the GUICtrlCreateLabel function, and comment the *VERT line, you will see it happens with the *HORZ style as well. #include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
Example()
Func Example()
Local $widthCell, $msg
GUICreate("My GUI")
$widthCell = 70
;~ GUICtrlCreateLabel("Line 1 Cell 1", 10, 30, $widthCell, 80, $SS_ETCHEDHORZ)
GUICtrlCreateLabel("Line 1 Cell 1", 10, 30, $widthCell, 80, $SS_ETCHEDVERT)
;~ GUICtrlCreateLabel("Line 1 Cell 1", 10, 30, $widthCell, 80, $SS_ETCHEDFRAME)
GUISetState()
Do
$msg = GUIGetMsg()
Until $msg = $GUI_EVENT_CLOSE
EndFunc ;==>Example
This occurs using AutoIt 3.3.8.1 and 3.3.9.4 |
|||
| #2366 | Fixed | For loop not working as expected | Jon | BrewManNH |
| Description |
Here's some code I came across that isn't working as it should, at least isn't working as I think it should work. Global $Array[5] = ["AA", "BB", "CC", "DD", "EE"]
For $I = -1 To $Array
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $I = ' & $I & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
Next
Global $Array[5][2] = [["AA", "1"], ["BB", 2], ["CC", 3], ["DD", 4],["EE", 5]]
For $I = 10 To $Array
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $I = ' & $I & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
Next
The output from the code above, when run from SciTE, is this.
The first value of $I is correct, it starts at whatever the For loop starts at, but then the For/Next loop starts acting like a For/In/Next loop. On a 2D array, the second section of code, it just loops for however many elements there are in the array, and the initial value of $I doesn't change. I would have expected this to either error out, because it's referencing an array instead of a number, or run once because there's no end number to reach. I have tested this code on 3.3.8.1, 3.3.6.1, and 3.3.9.5, 3.3.9.11 and they all run the same way. I don't think this should be working the way it is and appears to be a bug. Reopening this as the bug still exists, see previous bug report ticket |
|||
