Context Navigation

Timeline

7:49 AM Ticket #3817 (Double to Int64 type conversion - wrong results) updated by AspirinJunkie: The problem has already been reported here once: https://www.autoitscript.com/trac/autoit/ticket/3703 Anyway - the reasoning that this is not a bug is not correct. As explained here, rounding errors are not the cause, since these should only occur from 2⁵³ - not already from 2⁴⁹. Furthermore C/C++ gets along with this type conversion - only in AutoIt wrong results are produced. So the problem must be related to the internal handling in AutoIt.

3:24 PM Ticket #3820 (ProgressOn() - move feature) updated by mLipok: Summary changed
2:41 PM Ticket #3703 (2 ^ 49 and further return wrong results) updated by jchd18: Sorry but the "max precision of 15/16 digits" has nothing to do here. The max number of exact digits output by printf() and friends, as the example below clearly shows, is determined by the upper integral value stored exactly in a FP double. Direct cast from double to long long gives the correct result up to 2⁵³ (9007199254740992). You can check that the conversion from FP to string in plain C also is correct up to 2⁵³. So there is no valid reason why AutoIt would yield a wrong result below the limiting value, which is actually hardware-dependant (FP used in PCs has a 53-bit mantissa). Here's a very simple C program illustrating the facts: […] and here's the result: […]
2:00 PM Ticket #3820 (ProgressOn() - move feature) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
1:36 PM Ticket #3818 (InputBox() - TOPMOST option) updated by mLipok: Description changed
1:28 PM Ticket #3820 (ProgressOn() - move feature) created by mLipok: Please add feature which give enduser the ability to move the progress …

6:06 PM Ticket #3819 (_FileCountLines help file precision to add) created by Nine: _FileCountLines should say in help file that it allows File handle AND …

10:00 PM Ticket #3818 (InputBox() - TOPMOST option) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
9:39 PM Ticket #3818 (InputBox() - TOPMOST option) created by mLipok: Please add a feature to set InputBox() window as top most like …
10:02 AM Ticket #3817 (Double to Int64 type conversion - wrong results) created by AspirinJunkie: Following script: […] produces: $fN :562949953421312 (Double) …

5:45 PM Ticket #3816 (Improvement of the example in the help of the function ...) closed by J-Paul Mesnage: Completed: Added by revision [12515] in version: 3.3.15.4
10:00 AM Ticket #3816 (Improvement of the example in the help of the function ...) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
9:26 AM Ticket #3816 (Improvement of the example in the help of the function ...) created by domenic.laritz@…: The example in the help for the _WinAPI_ReadDirectoryChanges function …
8:54 AM Ticket #3815 (Remark in help regarding return value of _ArrayDelete is wrong) updated by domenic.laritz@…: Replying to Jpm: > The doc is not wrong as row index is starting at 1 so the size of the arraay is equal to the highest row index But this is contradictory to the function _ArrayAdd. There is the same text in the remarks as in _ArrayDelete, but the behavior is different (and in my opinion correct): _ArrayDelete actually returns the new highest index and not the number of rows!
7:35 AM Ticket #3814 (_WinAPI_CreateFileMapping: $PAGE_xxx constants not defined) closed by J-Paul Mesnage: Fixed: Fixed by revision [12513] in version: 3.3.15.4
6:45 AM Ticket #3815 (Remark in help regarding return value of _ArrayDelete is wrong) closed by J-Paul Mesnage: No Bug: The doc is not wrong as row index is starting at 1 so the size of the arraay is equal to the highest row index

9:07 PM Ticket #3815 (Remark in help regarding return value of _ArrayDelete is wrong) created by anonymous: The "Remarks" section of the _ArrayDelete function contains the …

10:54 PM Ticket #3814 (_WinAPI_CreateFileMapping: $PAGE_xxx constants not defined) created by matwachich@…

8:46 AM Ticket #3813 (_MemGlobalRealloc) closed by J-Paul Mesnage: Completed: Added by revision [12508] in version: 3.3.15.4

5:00 PM Ticket #3813 (_MemGlobalRealloc) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
4:14 PM Ticket #3813 (_MemGlobalRealloc) created by matwachich@…: Everything is in the title: It seems that this functions is laking …

4:12 PM Ticket #3812 (_DateTimeSplit never returns @error, and thus, any bad formated ...) closed by J-Paul Mesnage: Fixed: Fixed by revision [12502] in version: 3.3.15.4
4:10 PM Ticket #3812 (_DateTimeSplit never returns @error, and thus, any bad formated ...) updated by J-Paul Mesnage: I fix, I think, all your concerns "include" and doc about _DateIsvalid reference

8:59 PM Ticket #3812 (_DateTimeSplit never returns @error, and thus, any bad formated ...) updated by Jos: I think the documentation is wrong and shouldn't state that @error is returned as this function really is used as an helper function and not intended to check for validity of the date. You need to use _DateIsValid() for that. (which uses this UDF). This is all written a very long time ago so there most likely could be many improvements made now we indeed have regex to our disposal. :)
5:28 PM Ticket #3812 (_DateTimeSplit never returns @error, and thus, any bad formated ...) updated by Melba23: IMO the easiest way forward would be to add a single line to the function checking the date format: […] But no doubt a real RegEx guru could come up with a better pattern. M23

11:47 PM Ticket #3812 (_DateTimeSplit never returns @error, and thus, any bad formated ...) created by matwachich@…: _DateTimeSplit doc states […] But you see the code of the …

Note: See TracTimeline for information about the timeline view.