Timeline
May 29, 2014:
- 8:22 PM Ticket #2642 (The function Hex() returns the wrong value) updated by
- The following post by me appears to be related. http://www.autoitscript.com/forum/topic/161396-lamus/?p=1174073
May 26, 2014:
- 6:07 PM Ticket #2728 (Getting a window handle from PID for more advanced programs) closed by
- No Bug: Ask on the Forum if you don't understand AutoIt please. The example works as is intended.
- 3:59 PM Ticket #2728 (Getting a window handle from PID for more advanced programs) created by
- http://www.autoitscript.com/wiki/FAQ#How_can_I_get_a_window_handle_when …
May 24, 2014:
- 11:59 PM Ticket #2725 (Problem printing help file with multiple examples) closed by
- Fixed: Fixed by revision [10141] in version: 3.3.11.6
- 2:42 PM Ticket #2714 (Help for GUICtrlCreateGraphic omits info for dynamic graphics.) updated by
- The main point is that anyone trying to use this dynamically, will see the flicker and assume it's faulty. They may search the forum, find all the advice to use something more complicated, and give up. There is a simple fix, is it possible to get an example of the dynamic action in the help file without going 'way beyond'? Did you 'diff' the suggested new example v the current? The changes are + the bezier graphic from the GUICtrlSetGraphic help - this reduces the differences between the two help examples, which look like they started as one and diverged. 21 lines of code. (We could make it 14 lines but less pretty.) + a label by each graphic to make it easier to see which code makes each graphic. c. 6 lines of code. + a dynamic bar derived from Detefon's bar. - 21 lines of new code. You could miss out the first two changes, and only put the dynamic bar. The absolute minimum, would be to add the $WS_EX_COMPOSITED flag, then dynamic things will work correctly. Please consider doing this if nothing else.
May 22, 2014:
- 8:41 PM Ticket #2713 (ByRef Copy Bug) updated by
- Personally, I'm glad I know that. It is always better to know. Thanks for the info.
- 6:46 PM Ticket #2713 (ByRef Copy Bug) updated by
- I am sure it is possible to come up with a myriad scenarios where the interpreter does not do what someone thinks it should - just remember this is a free-to-use hobbyist language and you cannot expect perfection. Anyway, I am not getting into discussions in Trac - there is an open ticket which may, or may not, get fixed (it would not be high on my list for the next round of development work). Now you realise that the problem exists, I suggest you recast your code to get around it. :) M23
- 5:37 PM Ticket #2647 (Add line count of FileReadToArray to @extended) updated by
- Replying to anonymous: > If use FileSetPos and than pass file handle to FileReadToArray the @extended macro as count line would not make sense. I'm not looking to get the line count of the file, I'm looking to get the number of lines read into the array. FileSetPos has no effect on what I was asking about because you'd still be reading in a number of lines.
May 21, 2014:
- 7:36 PM Ticket #2713 (ByRef Copy Bug) updated by
-
Replying to Melba23:
> The comment:
>
> Should I do this every time I copy a variable that might be an array
>
> is nonsense as passing an array does not produce the error.
> […]
> Better still - pass the entire array rather then a single element and then the problem will never arise.
It doesn't matter that the
ByRefargument might be an array. Also, the following does exhibit the problem: […] > You can only pass an array element by using the [ # ] syntax, so you have an easy check on whether the problem will appear and can take measures to deal with it. I don't know if the function will be called with a reference to a "normal" variable or an "unnatural" array element. It's required that the argument is a reference, I need to modify it. The function also copies another argument (which may be an array). There are some possible solutions: 1. Duplicate the function and every function that forwards these two arguments: One version for "normal" variables and one version for "unnatural" array elements. If the other argument is an array, the second version forces AutoIt to copy the array, if the other argument really is an array. Then I will just need to call the adjusted function, if I use an "unnatural" array element. 2. Like the first with additional arguments indicating the kind of referenced object. 3. I could wrap the other argument to that function (and any other function like that) with a function like "identity" that simply returns the passed value when using an "unnatural" array element. 4. I could ensure that any copy of the other argument is a real copy, if that argument is an array. Again, I might use "identity". The first three are inacceptable, they would require the caller to do something which should be done automatically and reliably (by the interpreter), without needing to examine every single array access. The last two actually copy the other argument if it is an array, even when the copied array never contains the referenced object. - 2:15 PM Ticket #2727 (optional Datatypes) updated by
- Just to clarify (I am not on the forums): By "static" typing I meant that the type of every variable is known when the script is compiled/run and that errors are thrown when types don't match. This should then allow us to completely skip every check because it can be assumed that every variable already has the correct type, since the script wouldn't be running if that was not the case. But yes, I do understand why you are closing this.
- 12:32 PM Ticket #2690 (Win..... Return Value Proposal.) closed by
- Fixed: Fixed by revision [10136] in version: 3.3.11.6
- 8:44 AM Ticket #2713 (ByRef Copy Bug) updated by
- In my testing the problem only arises when you pass a single element of an array ByRef - passing the entire array produces what would be expected, regardless of whether the copy array is taken from the original or the passed array: […] The comment: Should I do this every time I copy a variable that might be an array is nonsense as passing an array does not produce the error. You can only pass an array element by using the [ # ] syntax, so you have an easy check on whether the problem will appear and can take measures to deal with it. Better still - pass the entire array rather then a single element and then the problem will never arise. M23
- 1:20 AM Ticket #2713 (ByRef Copy Bug) updated by
-
Replying to Mat:
> If you want to guard against this, then just force it to copy by writing to the array
That's an ugly hack. Should I do this every time I copy a variable that might be an array, if the function has a
ByRefargument (like$instance, the class generator creates countless arguments)?
May 20, 2014:
- 11:39 PM Ticket #2691 (Bitshift is returning incorect results) closed by
-
No Bug: Jchd is correct.
Of course if you want to get 52534 then you can just change it to
Int($number / 2^$bits) - 11:15 PM Ticket #2502 (COW optimization incorrect) updated by
- Further discussed in ticket #2713, and on the MVP forum here: http://www.autoitscript.com/forum/topic/161296-supposed-byref-bug/
- 11:13 PM Ticket #2713 (ByRef Copy Bug) closed by
- Duplicate: Replying to anonymous: > Is this connected to ticket 2502? Yes it is. I hadn't realised this had been looked at before (but it looks like the conclusion was similar (variable != r-value, and byref might use either, or might not). I'll close this as a duplicate. If you want to guard against this, then just force it to copy by writing to the array: […]
- 11:07 PM Ticket #2719 ("Misc. functions Reference" - table - Function list) updated by
- Just to keep everything tied together, this is being discussed in the MVP forum here: http://www.autoitscript.com/forum/topic/161503-2719-issue-with-the-build-scripts/ Issue has been confirmed (and partially fixed, possibly), but I can only take 10 minutes of reading the build scripts at a time before I feel the cone cells in my eyes melting.
- 11:02 PM Ticket #2727 (optional Datatypes) closed by
-
Wont Fix: You are correct that dynamic typing does incur a runtime overhead.
However, you are wrong that this would be "static" typing, and that they would perform any better. You'd still need to (at runtime) check the type of the variable and then do something different depending on the type. The only difference between that and a variant is that the explicitly typed case would result in errors, rather than casting.
I really like explicit typing. I am very fussy in compiled languages about type, you wouldn't even see me writing
float f = 4.0;in C++. But there really isn't any point in it, or need for it, in an interpreted langauge like AutoIt. I hope this explains why I'm closing this. If you still have any questions then feel free to PM me on the forums. - 9:42 PM Ticket #2727 (optional Datatypes) updated by
-
Replying to anonymous:
> If I remember it correctly then the variant datatype works by converting the content of the variables you are currently working with to the type that makes the most sense. If this is correct than it obviously has to be done every time the user works with a variable and therefore I guess that it slows AutoIt down a lot.
That wouldn't be a problem if the generated representation would be optimized. (I'm sure it isn't.)
> What I am asking for instead is a static type system that is completely optional, that works by adding new Keywords and that simply bypasses all the checks and conversions that are currently done.
[…]
That probably wouldn't help. Quite the contrary, the interpreter would need to check the types at every assignment.
Nevertheless I hope that one day static typing will be part of this language.
> Example:
> {{{
> Local $a, $b, $c ; no datatype specified -> Variant
> Local Int $i
> Local String $s
> Local Bool $f = ($a > $b)
> }}}
A trailing "
as" type qualifier works better with functions. That also requires only one new keyword. Example:func toString ($arg1 as int32) as stringIf I remember correctly, there is a project that tries to add this kind of static typing to the language, translating it into normal AutoIt. That reminds me of TypeScript… - 8:12 PM Ticket #2705 (ObjCreate - without register anything) updated by
- Approx. So I have a few questions: 1 because I just started to use it (Debenu .. UDF) I hope that it will be in the future an official part of AutoIt, not just experimental, and at the moment I understand that I can report any observed problems? 2 Since this function is experimental, it can just as in the case of: Volatile could be added to the documentation of some description, then the greater the number of developers having knowledge of it could to test it. Which in turn can accelerate change in the status of this functionality on STABLE.
- 8:04 PM Ticket #2727 (optional Datatypes) created by
- The fact that I could not even find one ticket about this probably …
- 7:37 PM Ticket #2713 (ByRef Copy Bug) updated by
- Replying to Mat: > The discussion was only among the MVPs, the developers have not yet commented. The majority of the conversation was about what actually caused the behaviour you were seeing. Is this connected to ticket 2502? > If by "language feature" you are asking whether you should rely on this behaviour in code, you definitely shouldn't. There are better ways to write your original code that avoid this issue. I may not even know that the argument is an element of the copied array (or object).
- 6:26 PM Ticket #2714 (Help for GUICtrlCreateGraphic omits info for dynamic graphics.) closed by
- Rejected: Please adhere to the AutoIt standards for example creation. As it stands the example which was suggested is way beyond the scope of what the help file is intended for. Thanks.
- 6:24 PM Ticket #2705 (ObjCreate - without register anything) closed by
- Rejected: The feature according to a former dev is experimental and thus has no place in the official documentation. If or when this feature is stable then the appropriate changes will be made.
- 6:21 PM Ticket #2721 (_Array... - proposal) updated by
- Slight modifications were made where applicable. Thanks mlipok.
- 6:20 PM Ticket #2721 (_Array... - proposal) closed by
- Fixed: Fixed by revision [10135] in version: 3.3.11.6
- 2:25 PM Ticket #2724 (_WinAPI_CreatePen - doc) updated by
- Those constants have nothing to do with CreatePen >> http://msdn.microsoft.com/en-us/library/dd162705(v=vs.85).aspx
- 2:24 PM Ticket #2724 (_WinAPI_CreatePen - doc) closed by
- Fixed: Fixed by revision [10134] in version: 3.3.11.6
- 12:42 PM Ticket #2726 (GUIListView, GUICtrlListView_GetGroupInfoByIndex) closed by
- Completed: Added by revision [10129] in version: 3.3.11.6
- 11:55 AM Ticket #2713 (ByRef Copy Bug) updated by
- The discussion was only among the MVPs, the developers have not yet commented. The majority of the conversation was about what actually caused the behaviour you were seeing. If by "language feature" you are asking whether you should rely on this behaviour in code, you definitely shouldn't. There are better ways to write your original code that avoid this issue. As to whether it's a bug, I don't know. I'd be inclined to say yes, other MVPs thought it wasn't though, so we'll leave it to Jon to decide.
- 11:28 AM Ticket #2726 (GUIListView, GUICtrlListView_GetGroupInfoByIndex) created by
- I use listview in my autoit projects and i need to know the GroupID …
- 9:51 AM Ticket #2647 (Add line count of FileReadToArray to @extended) updated by
- Why? It would more or less reflect the number of lines read and loaded.
- 8:58 AM Ticket #2647 (Add line count of FileReadToArray to @extended) updated by
- If use FileSetPos and than pass file handle to FileReadToArray the @extended macro as count line would not make sense.
May 19, 2014:
- 4:43 PM Ticket #2723 (FileConstants.au3 and FileSelectFolder.txt) closed by
- No Bug
- 12:33 AM Ticket #2713 (ByRef Copy Bug) updated by
- Replying to Mat: > This has been discussed Was there an outcome of the discussion? Is it a language feature?
May 18, 2014:
- 6:15 PM Ticket #2713 (ByRef Copy Bug) updated by
-
Description changed
This has been discussed here: http://www.autoitscript.com/forum/topic/161296-supposed-byref-bug/ (Link is to MVP section) I've changed the code in the report to be much simpler, without the OPs attempt to write object oriented AutoIt without objects. - 3:22 PM Ticket #2723 (FileConstants.au3 and FileSelectFolder.txt) updated by
- ok All is clear. Ticket can be closed.
- 3:18 PM Ticket #2725 (Problem printing help file with multiple examples) updated by
- ok thanks for claryfication
- 2:48 PM Ticket #2723 (FileConstants.au3 and FileSelectFolder.txt) updated by
- In the beta versions of AutoIt, the new select folder dialog is used instead of the old one, which ignores these flags. See #2481. The helpfile already references this: The new vista+ dialog style is used if possible, regardless of the Use New Dialog Style flag. With the vista dialog style the edit control and create folder buttons are always shown, ignoring the flags parameter, and the dialog text parameter sets the title of the window.
- 2:40 PM Ticket #2725 (Problem printing help file with multiple examples) updated by
- Link isn't broken, it's just a link to the MVPs section of the forum where we are trying to figure out what's wrong.
- 12:54 PM Ticket #2725 (Problem printing help file with multiple examples) updated by
- Link is broken.
- 11:10 AM Ticket #2725 (Problem printing help file with multiple examples) created by
- When printing the help file for _Excel_RangeCopyPaste only the first …
- 9:38 AM Ticket #2723 (FileConstants.au3 and FileSelectFolder.txt) updated by
- They work on Windows 8.1 too.
- 9:29 AM Ticket #2719 ("Misc. functions Reference" - table - Function list) updated by
- Opt is missing in the table of the HTML page. I will need to dig deep into the build script. What joy!
- 2:15 AM Ticket #2719 ("Misc. functions Reference" - table - Function list) updated by
- Ok nevermind I see you can close this ticket. Sorry.
- 1:57 AM Ticket #2719 ("Misc. functions Reference" - table - Function list) updated by
- I try to explain: YES: this is on tree in index NO: click in HelpFile Tree : Function Reference >>> Misc. Managment and now do not see on the tree but look in displayed document and you see.... […] and here is incomplete table see attachment
May 17, 2014:
- 5:51 PM Ticket #2723 (FileConstants.au3 and FileSelectFolder.txt) updated by
- I ask, otherwise Is it possible to obtain a directory selection dialog with the possibility to enter/type a path in a different way than using $FSF_SHOWCREATEBUTTON? This function is useful to me. btw. there is typo $FSF_SHOWCREATEBUTTON not $FSF_SCHOWCREATEBUTTON
- 5:44 PM Ticket #2723 (FileConstants.au3 and FileSelectFolder.txt) updated by
- Or I do not understand your speech. Or I do not fully agree with you. Check out my REPRO: […] On my Windows 7 Pro x64 script above clearly shows that changes as a result of the use of the Flag. By which at the moment I think they are not deprecated, unless I missed something and actually do not understand something. Please request further discussion. mLipok
- 12:48 PM Ticket #1919 (Native IPv6 support) reopened by
- 12:48 PM Ticket #2721 (_Array... - proposal) updated by
- Looks like most of these have already been dealt with by jpm. M23
- 12:43 PM Ticket #2723 (FileConstants.au3 and FileSelectFolder.txt) updated by
- I disagree with the need for yet another set of named constants - the flags are only valid in XP and are thus deprecated for all other OSes, which probably means the majority of AutoIt users. M23
- 12:41 PM Ticket #2719 ("Misc. functions Reference" - table - Function list) updated by
- In my 3.3.11.5 help file, AutoItSetOption is included in Function Reference list. Or are you talking of another list? M23
- 12:38 PM Ticket #2722 (FileSelectFolder - XP Only - BUG) closed by
- No Bug: This is not a bug - the flags only work in XP as is explained in the Remarks: The new vista+ dialog style is used if possible, regardless of the Use New Dialog Style flag. With the vista dialog style the edit control and create folder buttons are always shown, ignoring the flags parameter The statement "XP Only" is quite correct - the flags only work in XP. M23
- 12:31 PM Ticket #2724 (_WinAPI_CreatePen - doc) created by
- based on AZJIO: …
- 8:24 AM Ticket #2441 (_ExcelReadCell) updated by
- @water any reason why adding _Excel_Close($oExcel) is not closing adding _Excel_BookClose() does not help
- 8:04 AM Ticket #2720 (_ArrayBinarySearch - Wrong Description) closed by
- Fixed: Thanks, it was already fix for all _array in 3.3.11.6
- 7:16 AM Ticket #2723 (FileConstants.au3 and FileSelectFolder.txt) created by
- please add […] to FileConstants.au3 and I attach modified …
- 7:00 AM Ticket #2722 (FileSelectFolder - XP Only - BUG) created by
- in Parameteres in "flag" description: […] This is not true. It …
- 6:47 AM Ticket #2721 (_Array... - proposal) created by
- in _ArrayDisplay removed doubled word array "Displays a 1D or …
- 5:42 AM Ticket #2720 (_ArrayBinarySearch - Wrong Description) created by
- Now there is […] Proposal: […]
May 16, 2014:
- 4:14 PM Ticket #2441 (_ExcelReadCell) updated by
- 3.3.11.4 with the rewritten Excel UDF returns NULL (displayed result of IsKeyword is 2). Example: #include <Excel.au3> $oExcel = _Excel_Open() $oWorkbook = _Excel_BookOpen($oExcel, @ScriptDir & '\test.xlsx') $cell_1 = _Excel_RangeRead($oWorkbook, "test", "C1", 1, True) ConsoleWrite(IsKeyword($cell_1) & @LF)
- 12:00 AM Ticket #2719 ("Misc. functions Reference" - table - Function list) updated by
-
Version changed
Automatic ticket cleanup.
May 15, 2014:
- 11:33 PM Ticket #2719 ("Misc. functions Reference" - table - Function list) created by
- […] there is no AutoItSetOption / Opt in this table. But this …
- 8:04 PM Ticket #2716 (GUICtrlSetPos - Parameters proposal) closed by
- Completed: Added by revision [10127] in version: 3.3.11.6
- 6:41 AM Ticket #2718 (SplashOff - example proposal) closed by
- Completed: Changed by revision [10125] in version: 3.3.11.6
May 14, 2014:
- 11:33 PM Ticket #2718 (SplashOff - example proposal) created by
- current contents of the example: […] PROPOSAL: […] …
- 6:57 PM Ticket #2714 (Help for GUICtrlCreateGraphic omits info for dynamic graphics.) updated by
-
Type, Version, Component changed
- 3:11 PM Ticket #2717 (AutoIt Constants include files) closed by
- Fixed: Fixed by revision [10121] in version: 3.3.11.6
May 13, 2014:
- 10:17 PM Ticket #2717 (AutoIt Constants include files) created by
- […] This is not true. What about: #include <InetConstants.au3> ??
- 9:44 PM Ticket #2716 (GUICtrlSetPos - Parameters proposal) created by
- look in Remarks: […] There is talk about Default keyword. …
- 9:10 PM Ticket #2715 (mistake in helpfile) updated by
- Fixed. Thanks. M23
- 9:10 PM Ticket #2715 (mistake in helpfile) updated by
- The first one is actually 1/4th of the desktop, not 1/8th or 1/16th. You're dividing the width and height by 4, not 8 or 16.
- 9:09 PM Ticket #2715 (mistake in helpfile) closed by
- Fixed: Fixed by revision [10120] in version: 3.3.11.6
- 8:24 PM Ticket #2715 (mistake in helpfile) updated by
-
Local $hGUI = GUICreate("GDI+ test", $iW * $iScale, $iH * $iScale, -1, -1) ;create a test gui to display the rotated imageand another mistake in the same example... it should be display the resized image not display the rotated image - 8:05 PM Ticket #2715 (mistake in helpfile) created by
- There is small mistake in comment in the example on page …
- 4:16 PM Ticket #2712 (RegDelete, RegRead and RegWrite operate on the wrong "keyname".) closed by
- No Bug
May 11, 2014:
- 11:39 AM Ticket #2712 (RegDelete, RegRead and RegWrite operate on the wrong "keyname".) updated by
- You enconter the registry remapping between an .exe running in 32-bit mode unde a X64-bit OS THere is no bug from AutOit neither from Windows at least that they want to implement …
- 9:59 AM Ticket #2714 (Help for GUICtrlCreateGraphic omits info for dynamic graphics.) created by
- See …
May 10, 2014:
- 11:18 PM Ticket #2713 (ByRef Copy Bug) created by
-
In the following script, the presence of
ByRefcauses$b… - 6:24 PM Ticket #2712 (RegDelete, RegRead and RegWrite operate on the wrong "keyname".) created by
- RegDelete, RegRead and RegWrite operate on the wrong "keyname". Is …
- 5:00 PM Ticket #2711 (_IELoadWait() hung in case of unknown error) updated by
-
Version changed
Automatic ticket cleanup. - 4:38 PM Ticket #2710 (Operator Documentation) updated by
- Page amended. Thanks. M23
- 4:38 PM Ticket #2710 (Operator Documentation) closed by
- Fixed: Fixed by revision [10112] in version: 3.3.11.6
- 4:21 PM Ticket #2711 (_IELoadWait() hung in case of unknown error) created by
- I have Embedded IE and sometimes it error-out by showing "404" page …
- 3:01 PM Ticket #2710 (Operator Documentation) created by
-
"Language Reference - Operators" lists
&as an assignment … - 12:25 PM Ticket #2709 (AutoItSC.bin is missing from v3.3.10.2) updated by
- Thanks, ffdshow
- 9:05 AM Ticket #2709 (AutoItSC.bin is missing from v3.3.10.2) updated by
- Please ask questions in the forum. But if you look for #pragma in the Help file you will find the answer. M23
May 9, 2014:
- 9:02 PM Ticket #2709 (AutoItSC.bin is missing from v3.3.10.2) updated by
- Just a short question, related with this ticket opened by me: With AutoIt v3.3.10.2, I compiled a file, using the next command line "%ProgramFiles(x86)%\AutoIt3\Aut2Exe\Aut2exe.exe" /in "D:\uninst.au3" /out "D:\uninst.exe" /icon "D:\Icon.ico" /comp 4 /pack /x86 /gui All went fine, except file version, which is 0.0.0.0 Using AutoIt v3.3.8.1, without /bin switch, the compiler will write file version as 3.3.8.1 Thanks, ffdshow
- 3:04 PM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Replying to Lbsl: > Whatever AutoIT 3.3.8.1 did on the TCPRecv and Send functions, worked much more efficiently than it currently does in the 3.3.10.2 I overread the TCPTimeout comments above: I figured out that the TCPTimeout (which is set to 500msecs in my case) is executed also on the errors below 0. I don't think this is really necessary as these errors are certain not to resolve the stuff that the -x errors produce, without developer intervention. For sure the timeout should not be applied when the TCPRecv error is -1.
- 2:09 PM Ticket #2709 (AutoItSC.bin is missing from v3.3.10.2) updated by
- AutoIt no longer requires AutoItSC.bin and I have removed reference to it and the associated parameter from the "Compiling Scripts" page. Thanks for reporting it. M23
- 2:07 PM Ticket #2709 (AutoItSC.bin is missing from v3.3.10.2) closed by
- Fixed: Fixed by revision [10111] in version: 3.3.11.6
- 1:57 PM Ticket #2709 (AutoItSC.bin is missing from v3.3.10.2) created by
- AutoIt 3.3.10.2 doesn't have a file AutoItSC.bin in Aut2Exe folder, …
- 12:48 PM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- I stumbled upon the same problem. Also evaded it by ignoring errors < 0. But somehow this still does not solve the performance issue with tcprecv. It seems to me that the Tcprecv is not clearing its buffers when it transferred the data content to my own receive buffer variable. I have been running a simple client and server app that is parsing an enormous log-file from one side to the other. It seems to choke faster the smaller the receive buffer size i set. If i set it to receive 10.000 characters, the flow streams efficiently a lot longer yet eventually chokes as well (making the flow stutter), but if i set the receive buffer to 1K, it seems to choke much faster. Whatever AutoIT 3.3.8.1 did on the TCPRecv and Send functions, worked much more efficiently than it currently does in the 3.3.10.2 Cheers.
May 8, 2014:
- 9:33 PM Ticket #2708 (re calculate "to" statment in "for ... to" loop) updated by
- Allowing such a terrible behavior would uselessly slow down 99.99% of the loops using correct bounds and give a dramatic green light to 0.01% loops which attempt to use incorrect bounds due to overly lazy algorithm implementation. The correct implementation in such case requires a different condition, not a simple upper value in a For loop.
- 5:49 PM Ticket #2707 (Incorrect GUI client size) updated by
- Replying to anonymous: > > the edit control is too tall, and the bottom scroll bar gets hidden > See #2588 and use GUICtrlCreateMenu() after GUISetState() Thanks. I like to create all the controls while thw GUI is hidden, so I found a better solution. We just have to call GUISetState(@SW_ENABLE)immediatelly after creating the GUI. Then we can create all controls before calling GuiSetState(). Hope it helps to fix the bug.
- 5:49 PM Ticket #2707 (Incorrect GUI client size) updated by
- Replying to anonymous: > > the edit control is too tall, and the bottom scroll bar gets hidden > See #2588 and use GUICtrlCreateMenu() after GUISetState() Thanks. I like to create all the controls while thw GUI is hidden, so I found a better solution. We just have to call GUISetState(@SW_ENABLE)immediatelly after creating the GUI. Then we can create all controls before calling GuiSetState(). Hope it helps to fix the bug.
- 4:10 PM Ticket #2708 (re calculate "to" statment in "for ... to" loop) closed by
- No Bug: This is not a bug - it is how the language works. And I too dispute whether "other major programming languages" allow changes to the loop limits. Please open a "Feature Request" if you wish such a feature to be considered. M23
- 1:22 PM Ticket #2707 (Incorrect GUI client size) updated by
- > the edit control is too tall, and the bottom scroll bar gets hidden See #2588 and use GUICtrlCreateMenu() after GUISetState()
May 7, 2014:
- 9:44 PM Ticket #2707 (Incorrect GUI client size) updated by
- The info you got with the Au3Info tool demonstrates exactly what I mean. Initially, the window is created with 400x300 px. After adding the menu, the client hight should be 300 less that menu's height, which would make ~280 px. That's the expected behavior. Try creating a GUI with a menu in C. You'll see.
- 9:33 PM Ticket #2707 (Incorrect GUI client size) updated by
- Just run that script with both versions 3.3.8.1 and 3.3.10.2 and you'll see what I mean. I use WinGetClientHeight() to get the size of the client area after adding the menu. That allows me to create an edit control of the same size as the remaining client area, just like the notepad window. In the version 3.3.10.2, the edit control is too tall, and the bottom scroll bar gets hidden. It works fine in the version 3.3.8.1.
- 7:27 PM Ticket #2707 (Incorrect GUI client size) updated by
- What exactly are you demonstrating with the script posted? Where are you showing that WinGetClientSize isn't returning the correct size? When I run that script I get the following in the Au3Info tool. ---- >>>>> Window <<<< Title: Menu and edit example Class: AutoIt v3 GUI Position: 758, 417 Size: 416, 338 Style: 0x14CF0000 ExStyle: 0x00000110 Handle: 0x00000000007E0E70 >>>> Control <<<< Class: Edit Instance: 1 ClassnameNN: Edit1 Name: Advanced (Class): [CLASS:Edit; INSTANCE:1] ID: 4 Text: Position: 0, 0 Size: 400, 300 ControlClick Coords: 192, 101 Style: 0x503310C4 ExStyle: 0x00000200 Handle: 0x0000000000600BD4 ---- I'm not saying you're wrong, I'm just not sure what you're expecting to see and what you're actually getting.
- 5:49 PM Ticket #2708 (re calculate "to" statment in "for ... to" loop) updated by
-
Replying to TommyDDR:
> Should be the behavior of a for loop is the same as in other major programming languages.
> […]
> The output condition is currently not recalculated each loop while in C, C + +, java, it is. This could avoid some "dimension range excedeed" for example.
I'm not aware of any programming language with that kind of
for-toloop that recalculates thetovalue. The difference in C, C++, Java etc. pp. is that you need to explicitly calculate thetovalue before entering the loop because that is only a for a while loop. If that value is constant, the optimizer will probably do that for you. - 4:01 PM Ticket #2708 (re calculate "to" statment in "for ... to" loop) updated by
- That's how For loops work in AutoIt, the To condition is checked at the start of the loop and the $i variable is checked as you loop through it, but not the To value. You can't change the To condition dynamically.
- 1:18 PM Ticket #2708 (re calculate "to" statment in "for ... to" loop) created by
- Should be the behavior of a for loop is the same as in other major …
- 11:26 AM Ticket #2707 (Incorrect GUI client size) created by
- The script below worked fine in the version 3.3.8.1. When using the …
May 6, 2014:
- 5:08 PM Ticket #2647 (Add line count of FileReadToArray to @extended) updated by
- Have you looked at the latest version of _FileReadToArray? There's so much added code in there that it's definitely bloat when all you want to get is the line count. Adding it to the native version of FileReadToArray would put it in the exe and not in the script and would probably not add much to the overall size. Also, in regards to comment #7, if you disable the return count in 0, then you're just using FileReadToArray, which means your point is moot, because the whole point of this request was to get an easy way to get the line count. My whole request is to leave the functionality of FileReadToArray alone, by leaving the return as a zero based array, and adding the count in @extended. Without having to resort to using File.Au3, or _FileReadToArray.
May 5, 2014:
- 4:34 PM Ticket #2706 (error in $tagWINDOWINFO) closed by
- Fixed: Fixed by revision [10109] in version: 3.3.11.6
- 3:54 PM Ticket #2706 (error in $tagWINDOWINFO) updated by
- Constant is in WinAPISys.au3.
- 3:54 PM Ticket #2706 (error in $tagWINDOWINFO) updated by
- Constant is in WinAPISys.au3.
- 2:00 PM Ticket #2706 (error in $tagWINDOWINFO) updated by
-
Version changed
Automatic ticket cleanup. - 1:26 PM Ticket #2706 (error in $tagWINDOWINFO) created by
- didn't find in bugtracker... so - error in: […] rWindow & rClient …
- 9:01 AM Ticket #2705 (ObjCreate - without register anything) created by
- I used functionalities described below. Very useful and above all …
May 4, 2014:
- 5:24 PM Ticket #2703 (Soundsetvolume doesn't work with object) closed by
- Duplicate
- 4:59 PM Ticket #2703 (Soundsetvolume doesn't work with object) updated by
- Error in title, please delete
- 4:58 PM Ticket #2704 (soundsetwavevolume doesn't work with object) created by
- In the following code soundsetwavevolume works when audio is played …
- 4:57 PM Ticket #2703 (Soundsetvolume doesn't work with object) created by
- In the following code soundsetwavevolume works when audio is played …
May 3, 2014:
- 10:59 AM Ticket #2702 (_ArrayTranspose - Return Value - proposal) closed by
- Completed: Added by revision [10102] in version: 3.3.11.6
- 9:24 AM Ticket #2702 (_ArrayTranspose - Return Value - proposal) updated by
- The beta is correct. See other ticket.
- 9:04 AM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) updated by
- My example showed that the function is working correctly with an empty array, which is what $aArray[0][2] is. The test UBound($avArray, 0) being zero denotes that the variable is zero-dimensional, which means it is a flat variable (not an array). Transposing a flat variable should leave it unchanged and should definitely not raise an error, which the function again does correctly. To see why this behavior is the mathematically correct one, see a flat variable as $vVar[1] and transpose this "vector". There is no point at all in raising an error when a sensible answer is possible.
- 7:03 AM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) updated by
- some doc precision was needed …
- 7:01 AM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) closed by
- Fixed: Fixed by revision [10098] in version: 3.3.11.6
- 5:00 AM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) updated by
- I never said the example posted was an empty array, what I said was that the function doesn't return an error on an empty array. It just returns with a return value of 1 and does nothing, that is the bug. […] Unless someone else thinks that not returning an error on an empty array is a good idea, this is the bug I'm talking about. The example posted is demonstrating that in older versions of _ArrayTranspose the function would return an error if sent a 1D array. In investigating this I found the code above that showed me that there was a bug in the code, unrelated to 1D array handling. Also that the function now handles 1D arrays but there's no mention of it in the help file.
- 3:24 AM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) updated by
- The function has no bug here. First $aArray above is not an empty array: it is an uninitialized 1D array, that is a 10-dimensional column vector. Then its transpose is correctly made a 10-dimensional row vector, which in AutoIt has the form $aArray[1][10] and is displayed accordingly. Transposing really empty arrays shouldn't produce an error either and the function correctly works as well: the result displays as $aArray[2][0], which is exactly what is expected. […] OTOH the beta help file could indeed be made clearer about the behavior.
- 2:52 AM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) updated by
- Both. They're unrelated to each other, but there are problems with the function and the help file. One is that the function doesn't return an error for an empty array, second is the help file doesn't explain that it works with 1D arrays now and not just 2D arrays.
May 2, 2014:
- 2:36 PM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) updated by
- hmm... but is it a bug in UDF or in HelpFile ?
- 2:22 PM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) updated by
- There's definitely a bug in the new version. If the array is empty it returns 1 which is supposed to signify success, and also it appears that the documentation needs to be updated to indicate that it works with 1D arrays now as well as 2D arrays.
- 12:00 PM Ticket #2702 (_ArrayTranspose - Return Value - proposal) updated by
-
Version changed
Automatic ticket cleanup. - 11:01 AM Ticket #2702 (_ArrayTranspose - Return Value - proposal) created by
- Please consider to add new @error return […] REPRO (actual its …
- 10:55 AM Ticket #2701 (_ArrayTranspose() - Bug in Func or in Doc) created by
- in section: Return Value […] REPRO: […] Au3 3.3.10.2 Console …
- 7:14 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Thank you for taking the time to investigate the matter. I appreciate the Autoit3 team's hard work and you guys/gals are doing an amazing job! Thanks again.
May 1, 2014:
- 11:33 PM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- I agrre that my TCPConnect timeout solution must be committed I will speak with Jon which is the only one which can commit for AutoIt change
- 10:58 PM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Too bad that don't work for connected WEB BROWSER clients. 3.3.10.2 STILL can't detect 10054 and MUST rely on other means to detect the error when a client connects to the server with a WEB BROWSER! Even then the error is 10053 (PROTOCOL ERROR) and not a TIMEOUT because the socket is long closed on client side before any kind of time out (On client side) can occur. I say it again! 3.3.10.2 CAN NOT detect 10054 when a web browser like CHROME OR anything else connects to the server... The last two above scripts are the PROOF of it...! (comment 30 31 should be enough to proof that 3.3.10.2 TCPRecv @error detection is BROKEN when detecting client side closed browser sockets where 3.3.8.1 had no problems what soever!) Thank you for your time.
- 7:53 PM Ticket #2690 (Win..... Return Value Proposal.) updated by
- jpm I understood your statement. However, perhaps my post was an understood differently than I wanted. I'll be back over the weekend to this topic.
- 3:55 PM Milestone 3.3.11.5 completed
- 3:26 PM Ticket #2648 (FileSaveDialog extension value) closed by
- Fixed: Fixed by revision [10093] in version: 3.3.11.5
- 8:26 AM Ticket #2700 (_GUICtrlRichEdit_SetCharBkColor()) closed by
- Fixed: Fixed by revision [10091] in version: 3.3.11.5
Apr 30, 2014:
- 8:41 PM Ticket #2700 (_GUICtrlRichEdit_SetCharBkColor()) updated by
- sorry I forgot REPRO: […]
- 8:23 PM Ticket #2700 (_GUICtrlRichEdit_SetCharBkColor()) created by
- from HelpFile: […] here is a solution to the UDF: […] And …
- 6:02 PM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Can you switch the discussion to Forum as too may post for a track report. For me the uploaded version for solving the TCPConnect timeout and clarification of @error is enough to have a good handling of peer disconnection as @error is set to 10054 which exactly what MSDN is describing WSAECONNRESET = 10054 Connection reset by peer. An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
- 8:35 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Whoops sorry, that one before this one got messed up somehow... This one should do better. […]
- 8:28 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- For the sake of clarity, this is a working example of 3.3.8.1 with proper @error detection set for the installation of genuine Autoit3 v3.3.8.1 and modified to remove server response to lesson the confusion. When executed with 3.3.8.1 the script will close the socket as expected. When executed with any other script greater than this version problems may arise! Newer version require the comments to be removed, and @error detection be > 0... And I believe without any further testing that this is the root difference between diegomainster's working examples and my failing examples.(Not tested elsewhere except the recent reproduction scripts). Thank you all for helping me understand the new TCPRecv function. Still don't care to add TimerInit, i'll stay with 3.3.8.1 for TCP related scripts until it is more user friendly(if ever). Please update the example 'help' scripts for TCPRecv to reflect these changes if you had not already, or aren't planing to do so. (They are amazing and taught me everything I know, thank you for that) TCPStartup() $serversock = TCPListen('127.0.0.1', 81) If @error Then Exit ; we know this one. While 1TCPRecv Do $hi = TCPAccept($serversock) If @error Then Exit ; we know this one. Until $hi <> -1 MsgBox(0,"Connected","A client has connected...") $ti = TimerInit() While 1 TCPRecv($hi,1500) If @error Then MsgBox(0,"Closed","Closing the connection: " & @error) TCPCloseSocket($hi) ExitLoop EndIf #cs If TimerDiff($ti) > 99 Then TCPSend($hi, 'data') If @error Then MsgBox(0,"SEND ERROR!",@error) $ti = TimerInit() EndIf #ce WEnd WEnd
- 8:07 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- In 3.3.8.1 it is even simpler than i describe it.. All you need is an @error of any kind to close the client side socket. Newer versions require you to ignore @error -1 plus do a timer init delay before sending data. (If I understand correctly)
- 7:17 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Replying to diegomainster@…: > Now I understand the problem you described, and me using your code also happened in version 3.3.8.1. I also tested the scripts with both versions. And 3.3.8.1 did not reflect the same problems as newer versions. I will assume that when you ran your scripts that @error was still set to > 0. (Easy miscalculation to do and would not hold it against a master coder like you or anyone else to oversee, I have done it countless times) But I realize assumptions are often misleading and am willing to diagnose why my version of 3.3.8.1 worked when @errror level is set properly for the version that is installed, when yours did not. 3.3.8.1 requires @error of any kind in order to close the socket.(Wow that is easy!) Later versions seem to require an error > 0... Or oven perhaps less than -1... definitely not an @error of -1 whatever you do. (@error -1 is worthless, and same as blank, why do we need two?) Later version also seem to require some kind of delay witch TCPRecv never ever ever needed before. TimerInit seems to be the main root of why my scripts fail and your scripts succeed.(Best guess so far) Bottom line: Version 3.3.8.1 - When I tested did not require a TCPsend nor TimirInit delay, in oder to close the socket. Later versions - Seem to require TimirInit before a response/closing. (Which is confusing but i'm ok with as long as there is proper documentation on how to implement the function because Autoit3 is great and should be available to use for everyone, not just elites. And that is what they have done to the best of their ability so far, and I'd hate to say that TCPRecv is not user friendly when it is possibly the most common used function of all time) Once again I appreciate your patients in dealing with a guy like me who is a newbie to forums and coding, Autoit3 has been good to me for a long time and it upsets me that something I have been using for years no longer works the way I expected. Now come on lets be honest please, which would you prefer... 3.3.8.1 needs no further action other than @error -1 to close a socket... Later versions require a time delay, plus you got to ignore @error -1 because it is...??? uhh... Blank i guess, same as the return value? -1 = "" ok.... @error > 0 close socket... Oh plus developers got to make new example scripts to help newbies to learn. (Not that hard, but wow, 3.3.8.1 TCPRecv was so much more user friendlier) You tell me which is not going to confuse the heck out of somebody who is learning TCPRecv. 3.3.8.1 @error -1 CLOSE THE SOCKET (DONE) 3.3.10.2 @error > 0 CLOSE THE SOCKET (OOOPS you forgot the time delay! TRY AGAIN!!!) Not trying to be disrespectful just trying to make a point. Sorry for the offence if any. My overall goal is to help Autoit3 be the best it can be, and they probably are doing a great job without me, but the TCPRecv is my lively hood and means a lot to me. I have no problem staying with 3.3.8.1 for the rest of my days if that is all I can get to work for TCPRecv heavy scripts. Thank you for your time. I still love Autoit3, and they still deserve all the donations they can and will get.
- 5:25 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Now I understand the problem you described, and me using your code also happened in version 3.3.8.1. I realized that if you call TCPSend() sometimes, TCPRecv() detects the closing of the connection, as in the code below: […] So, there is even a problem with TCP in autoit.
- 2:42 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Sorry but this is driving me NUTS! I'm sorry for spamming your forum. If there is no TCPRecv error then why the holy molly is it so hard to work with now? Why in gods name is this not working???? When diegomainster example server/client scripts can detect the error without a problem? I concede that it is probably my scripting but what the heck happened that made TCPRecv so hard to deal with now?!? What in the world am I doing wrong? If you can explain this to me that would be great, in the meantime i'll search for a new place to research this. When I run this script and open a web browser and goto the address and then close the browser the script does not detect @error > 0 !!! Please explain to me if TCPRecv is not bugged, what in the WORLD am I doing wrong here? […]
- 12:57 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Sorry miss spoke again. I can receive the message, just can't detect the @error > 0 in order to close the socket. Sorry for wasting your time.
- 12:57 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Sorry miss spoke again. I can receive the message, just can't detect the @error > 0 in order to close the socket. Sorry for wasting your time.
- 12:50 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- I've done everything I know of to try and make your solution work without any success at all. I've tested it on three different operating systems and still nothing. I'm very confused at this point why @error > 0 will work for you when I can't even get a received message most of the time using that. Guess i'm SOL. If you have any last suggestions or ideas on what I need to fix in the reproduction script then please share them. I don't want to be stuck on 3.3.8.1 forever and am very curious as to what i'm doing differently that it will work for you and not me. I've tried everything I can think of and am ready to concede the subject and just live with what I've got. Thanks.
Apr 29, 2014:
- 11:36 PM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- I created a video to demonstrate it on my web server when the browser closes the connection, the connection is closed, don't "stays open forever": https://www.youtube.com/watch?v=_s0KJGPtXgw
- 4:56 PM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Ran tests on a different operating system and it confirmed that TCPRcv still can not detect a client side closed web browser socket as older versions did. I tried the @error > 0 solution and still was unable to detect the client side closed web browser socket via @error 10054. Socket stays open forever even when the browser is closed. Something is off there and it is killing autoit3's ability to function efficiently as a web server. Even worse try mixing the two together as a script that can do web serving and accept persistent autoit3 client connections. Can be done but 3.3.8.1. will out speed any newer version scripts at the same time be more reliable. If you wish to continue thinking there is nothing wrong with TCPRecv then fine i'm ok with that. Future autoit3 users should be aware that scripting a web server with the newer versions wont be as effective. 3.3.8.1 will dominate over newer scripts with speed and rely ability. You might as well retire any thought of having a descent web servers using autoit3 for here on out if the issue is not resolved. Good luck.
- 10:03 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Sorry for junking things up, just wanted to let it be known that the extra TCP connections were obviously something my browser was doing and was able to fix it by turning off a setting. (Just never seen that before and was confusing me)... That issue has nothing to do with autoit3 and i'm sorry for bringing that up. If you need more insight on the @error for new versions then i'd have to make a video of exactly what i'm experiencing over here to show you, if the new repro script does not help at all. Thanks for your time.
- 8:01 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Sorry I was afraid you were going to close the ticket before I could finsih... Here is the reproduction script. Well here it is, hope it helps. Remember the only way to reproduce the error that I know of is two use un-install and re-install between 3.3.8.1 and 3.3.10.2 This also creates a junk file to quickly simulate outgoing requests. Hope that is ok. […]
- 7:51 AM Ticket #2699 (_ArrayAdd $hDataType not documented) closed by
- Fixed: Fixed by revision [10084] in version: 3.3.11.5
- 7:43 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Would you like to see my repro script?
- 7:42 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Sorry it is not working fine, I have tested all day and it is still not as good as old versions…
- 7:41 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Replying to diegomainster@…: > Hello, I created this ticket, once I started ignoring @error = -1, my server is running fine, I'm using version 3.3.10.2, created these 2 scripts to demonstrate how do I detect when the client or server closes the connection, it works for me: > > Server: http://pastebin.com/JPf3A8KE > Client: http://pastebin.com/irVGLpde Thank you for the examples. I'm glad that is working for you. This does not work for what i'm doing. The only difference I can tell here is that i'm not using a Autoit3 client side version to connect to the server. (Don't know why that matters.) Same problem, Autoit3 server can't tell when client web browser closes the socket where older versions could. I'm trying to get an example script working that will show case exactly what is happening between version 3.3.8.1 and the newer version 3.3.10.2 that will hopefully not make things even more confusing. This is what i have learned so far. Autoit3 v3.3.8.1 installed by using the setup download. Works as expected... Autoit3 v3.3.10.2 installed by using the setup download. @error -1 is different, and causes problems when detecting a web browser closed socket. > 0 @error does not help here for whatever reason. Installing the beta version.exe did not seem to help. HOWEVER. When using the beta version on 3.3.8.1 there does not seem to be the problem that genuine 3.3.10.2 installs seem to have.(This was very confusing to me when making the trouble shooting script because I was assuming that it would not work.) So unless you know a better way then I would recommend using the setup installers for switching between autoit3 versions. Uninstall-reinstall between 3.3.8.1 and 3.3.10.2 and then run the bellow repro script. HOWEVER! This too cause me problems! But I do not want to get into detail about it other than to warn you that when I was installing between versions that version 3.3.8.1 was acting out of character and I had to download a fresh copy of the 3.3.8.1 to correct it. (Was getting extra TCP connections to the server that sent no data but would eventually close) Before I was just swapping out exe files between beta and 3.3.8.1 when making this script, but the problem does not seem to start until you install the genuine 3.3.10.2 and then try swapping out with the beta version.
- 7:40 AM Ticket #2596 (TCPRecv not returning data, and setting @error to -1) updated by
- Many thanks, Now I understand better (I think ?) If the connection is closed by the other side you received in 3.3.8.1 -1 now with my TCPConnect implementation you received 10054 which means connection reset by peer which is better as the @error less than 0 can set in other situation I Think you can agree that my TCPConnect() timeout solution is working fine as 3.3.8.1 Cheers Jpm
Note:
See TracTimeline
for information about the timeline view.
