Timeline



Oct 18, 2015:

3:15 PM Ticket #3140 (@error Description) updated by Melba23
mLipok, There is no "defined" value in the sense that the value is dependent on the function itself - each one may have a different value. But I see what you mean - the advantage of having non-native speakers to check the wording! Would it be better if it read: If the Return value method is used, each function will specify in the Help file the specific return value for success - but the value is typically non-zero to allow easy to read code... I do not believe that referring to @extended is useful here - it is only likely to confuse as many functions do not use it. M23
3:07 PM Ticket #3142 (Auto-Complete in SciTE) closed by Melba23
Rejected
5:05 AM Ticket #3112 (Function _Excel_RangeFind not working) updated by pvp
Hello, I want to ask when u finish 3.3.15.1 version ? function _Excel_RangeFind is error, so... I cant do anything :((

Oct 17, 2015:

5:23 PM Ticket #3141 (Wrong Screen Size Dimension Problem in Windows10 in Combination with ...) updated by BrewManNH
I stand corrected on the first PDF, I missed the screen size in that one as it wasn't showing me the whole PDF when I viewed it for some reason. The second one is not helpful to me as I don't read or speak German, and by the way doesn't indicate that you set it to 150% anywhere on the image. I'd say that AutoIt is giving you the correct screen size, as you've blown it up by 150%, so the resolution changes when you do that, doesn't it? Just because you set it to 2160x1440 now that you've magnified it, the real resolution is 1440x960.
2:53 PM Ticket #3141 (Wrong Screen Size Dimension Problem in Windows10 in Combination with ...) updated by J-Paul Mesnage
In Fact I try to reproduce your problems. I can't The second problem as the sizes are correct even without reconnecting as it is required. The first problem I don't know who is right as after reconnection the scrren is really reduced but the windows control panel infact still indicates the sizes before using the text Definetelty the AutoIt return values must be used to be in adequation with the pixel that can be used. So for me it is not an AutoIt Bug perhaps a Windows anomaly
1:50 PM Ticket #3142 (Auto-Complete in SciTE) updated by mLipok
check in au3abbrev.properties you can set your own in: au3UserAbbrev.properties search for them here: c:\Users\user\AppData\Local\AutoIt v3\SciTE\ EDIT: btw. if you are so lazy please use forum instead Track because this would be much easier to post for you, a question there.
11:02 AM Ticket #3142 (Auto-Complete in SciTE) created by anonymous
My laziness make me wish for Auto-Complete function in SciTE should be …

Oct 16, 2015:

10:15 PM Ticket #3141 (Wrong Screen Size Dimension Problem in Windows10 in Combination with ...) updated by k.knetsch@…
Sorry, but that is not true. In the first PDF you can see on the left side the current ScreenSize in the windows 10 dialog which is 2160x1440. But Autoit gives me in the msgbox only 1440x960! I am expecting 2160x1440, because my scripts which depends on positions won´t work under windows 10. If I take an full screenshot by autoit for example, I won´t get a full screen, it is just a snippet of 1440x960! I have found out that the reason for that seems to be the preferences of „size of text apps and other items“ (which is in german called "Größe von Text, Apps und anderen Elementen"), what you can see in the second pdf. Here you can see that I have at first a value of 150% (in the first slider), which gives me back in autoit an resolution of 1440x960. But after choosing the slider to a value of 100% the resolution changes and autoit gives me then right resolution of 2160x1440. Surely it is possible to change this setting every time I want to use autoit, but I think that can not be the solution. I have test scripts which I have to spread out to users, so I cannot expect from them to change this adjustment every time. For other comparable tools there seems to be no problem. I have checked how autohotkey would behave and there is not such a problem. It shows me the right resolution of 2160x1440 independentliy from any adjustment in the described matter. I still want to use autoit furthermore, so can you help me and others with the problem?
8:58 PM Ticket #3141 (Wrong Screen Size Dimension Problem in Windows10 in Combination with ...) updated by BrewManNH
Neither of those pdfs show what the problem you're saying actually is? What is the screen size you're expecting and what are you getting? Are you taking the taskbar into account?
6:33 PM Ticket #3140 (@error Description) updated by mLipok
one problem in reading and my understanding: […] is this intentional or this should be not used ? ---- […] additional description proposal: […] ---- and some other Additional description proposal: […]
5:51 PM Ticket #3140 (@error Description) updated by Melba23
How does this read? Success/failure indication Some functions use the Return value to indicate success/failure, others set the @error flag. Some do both.... If the Return value method is used, there is no defined value for the return but it is typically non-zero for success to allow easy to read code... […] If the @error flag method is used, @error = 0 always indicates success. Other values are as defined in the Help file for the specific function. […] If a function uses the @error flag method, you should always check the flag before attempting to use the return value - if the flag is set then the function return value is generally undefined... M23
8:38 AM WrongScreensizes2.pdf attached to Ticket #3141 by k.knetsch@…
Further Details Screens2
8:30 AM WrongScreensizes.pdf attached to Ticket #3141 by k.knetsch@…
Further Details Screens
8:04 AM Ticket #3141 (Wrong Screen Size Dimension Problem in Windows10 in Combination with ...) created by k.knetsch@…
The detection of the right screen size under windows 10 is wrong. It …

Oct 15, 2015:

5:56 AM Ticket #2320 (_IENavigate return values) updated by philkryder
this still seems to be a problem in more current versions for some of the functions. see: https://www.autoitscript.com/forum/topic/177987-error-using-ielinkclickbytext/?page=2
3:24 AM Ticket #3097 (AutoIt crash with Objects) updated by mLipok
There is no error if "c:\Program Files (x86)\AutoIt3\AutoIt3_x64.exe" is used. Error occurs only with: "c:\Program Files (x86)\AutoIt3\AutoIt3.exe" And here can be usefull information: https://www.autoitscript.com/forum/topic/174281-autoit-error-in-ie11/?do=findComment&comment=1277637 […] EDIT: My testing System is Win 7 Pro 64BIt IE 11.0.9600.18059

Oct 14, 2015:

6:22 AM Ticket #3140 (@error Description) updated by J-Paul Mesnage
I don't know who wrote this page but it can be Jon himself since the wording is the same as in the first introduction in 2006 I am not either an English corrector so Just wait English fluent people validate the proposal

Oct 13, 2015:

8:00 PM Ticket #3140 (@error Description) updated by TicketCleanup
Version changed
Automatic ticket cleanup.
7:53 PM Ticket #3140 (@error Description) created by mLipok
here: https://www.autoitscript.com/autoit3/docs/function_notes.htm
1:20 PM Ticket #3139 (FileGetTime out by exactly one hour.) updated by jchd
Contrary to what you claim, the correct time for a decent filesystem is UTC. Want it or not this is the only non-contradictory possible convention and this is unsurprisingly what NTFS uses. Also your "fix" is wrong, you should be using _Date_Time_FileTimeToLocalFileTime. Can we now stop discussing this in Trac, this is definitely not the place for that. "No bug" confirmed.
9:47 AM Ticket #3139 (FileGetTime out by exactly one hour.) updated by anonymous
Ignore the variable names! Brainfart. ;o)
9:43 AM Ticket #3139 (FileGetTime out by exactly one hour.) updated by anonymous
For anyone finding this page, here is something which should be in the manual page for FileGetTime (after the big notice that AutoIt will return incorrect results if you happen to be inside daylight saving time, which should matter not one jot). […] NOW you have the correct date/time. What a pain. ;o) Cor
9:18 AM Ticket #3139 (FileGetTime out by exactly one hour.) updated by anonymous
Some feedback about this in the forum would have been better, of course, but I've been waiting since July for that. I read the document you linked to. It seems to say that AutoIt is incorrectly retrieving the modification date, not taking into account local daylight saving time. I would concur. This is commonly known as a "bug". If you are telling me that *I* am doing something wrong and that there is another way to get the actual, correct modification time, then please share! How will changing the status to "no bug" stop AutoIt from producing the wrong results. The modification time is incorrect. It is obviously a bug!
1:42 AM Ticket #3103 (_Timer_GetIdleTime not working properly in Windows 10) closed by BrewManNH
Works For Me
1:41 AM Ticket #3139 (FileGetTime out by exactly one hour.) closed by BrewManNH
No Bug: It's not a bug in AutoIt, it's how the Windows API for file times works. https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 Windows files times are in UTC and then adjusted for the time zone you're in, UTC isn't affected by daylight savings time.

Oct 12, 2015:

10:55 PM Ticket #3139 (FileGetTime out by exactly one hour.) created by corz
I have a regular file, a movie. In Windows (8.1 x64) properties …

Oct 8, 2015:

6:22 PM Ticket #3138 (GUIRegisterMsg - add to chain) closed by Melba23
Rejected: Jon has already stated that this will not be done. M23
8:52 AM Ticket #3135 (StdioClose with $STDERR_MERGED memory leak) updated by J-Paul Mesnage
For me the StdIoClose() can do a definitive cleaning only if the process is really close so that normal it should be post after to have a complete cleaning The Stream reading must be available by StdOutRead() or StdErrRead() after the process closing. So If you don't do it StdIoClose() will do it for you. I hope I understand the AutoIt implementation. I leave to Jon the final answer

Oct 7, 2015:

6:23 PM Ticket #3138 (GUIRegisterMsg - add to chain) created by anonymous
As written in help: GUIRegisterMsg - Register a user defined function …
3:53 PM Ticket #3135 (StdioClose with $STDERR_MERGED memory leak) updated by Jos
Correct or the other option is to replace the StdioClose() by a loop that reads the STDIO buffer until it has read everything. This will also avoid the leaking. Jos
12:26 PM Ticket #3093 (_FileWriteToLine() option to create a new line if it doesn't exist) updated by Melba23
Added by revision [11561] in version: 3.3.15.1
12:25 PM Ticket #3093 (_FileWriteToLine() option to create a new line if it doesn't exist) closed by Melba23
Completed: Added by revision [11560] in version: 3.3.15.1
10:30 AM FileRead_UTF-8_Bug.au3 attached to Ticket #3137 by miraged
Repro
10:29 AM Ticket #3137 (FileRead() treats count parameter as bytes instead of characters for ...) created by miraged
When reading from UTF-8 files (with or without a BOM) the count …
9:15 AM Ticket #3135 (StdioClose with $STDERR_MERGED memory leak) updated by jvanegmond
Replying to anonymous: > but it seems there is also a leak when you comment the StdioClose()statement. Could it be that ProcessClose() isn't cleaning up when STDIO is used for the process? Interestingly, the only order which does seem to work is the exact one you posted on the forum where you call StdioClose after ProcessWaitClose. Any other order and it leaks memory.

Oct 6, 2015:

5:52 PM Ticket #3135 (StdioClose with $STDERR_MERGED memory leak) updated by anonymous
Agree there is a bug there somewhere. Firstly the posted script is what the helpfile also advertises and has a memory leak, but it seems there is also a leak when you comment the StdioClose()statement. Could it be that ProcessClose() isn't cleaning up when STDIO is used for the process? Jos
2:57 PM Ticket #3135 (StdioClose with $STDERR_MERGED memory leak) updated by jvanegmond
Jpm, the problem is solved. However, AutoIt methods should never leak memory. They should prevent the memory leak or catch the conditions where they can leak and return and set @error instead. Doing otherwise is unnecessarily confusing and placing the burden on end-users which we should not want. In this particular case, because the problem only happens with $STDERR_MERGED defined, I would guess it is probably an oversight inside of StdioClose or ProcessClose for that particular case.
8:38 AM Ticket #3135 (StdioClose with $STDERR_MERGED memory leak) updated by J-Paul Mesnage
If I understand well you just miss a StdIoClose($pid) at the right place as suggested by Jos

Oct 5, 2015:

2:46 PM Ticket #3136 (_FTP_DirPutContents Help File return value error) closed by J-Paul Mesnage
Fixed: Fixed by revision [11559] in version: 3.3.15.1
1:14 PM Ticket #3136 (_FTP_DirPutContents Help File return value error) created by Danyfirex
I was working with FTP udf (#include <FTPEx.au3>) and check for …
9:36 AM Ticket #3135 (StdioClose with $STDERR_MERGED memory leak) created by jvanegmond
The following AutoIt code when run on my machine by AutoIt v3.3.15.0 …
2:31 AM Ticket #3133 (Win* functions to set @error or @extended flag in case of fail / timeout) closed by BrewManNH
Rejected: How would that make the code more readable or simpler? It already tells you it's failed by not returning 1, I don't see any gain to be made by adding an error code that has no meaning. It's just as readable and, frankly, simpler to write this: […] As it is to write this […]

Oct 4, 2015:

8:32 PM Ticket #3134 (Missing GetSystemMetrics Constants in WindowsConstants.au3) closed by J-Paul Mesnage
Fixed: Fixed by revision [11557] in version: 3.3.15.1
1:36 PM Ticket #3134 (Missing GetSystemMetrics Constants in WindowsConstants.au3) created by anonymous
Please add missing from WindowsConstants.au3 GetSystemMetrics …

Oct 2, 2015:

11:23 PM Ticket #3133 (Win* functions to set @error or @extended flag in case of fail / timeout) created by anonymous
Now Win* functions have only one return value: Success: a handle to …

Sep 30, 2015:

4:02 PM Ticket #2995 (Create and pass array as parameter in the parameter itself) closed by Melba23
Rejected
4:01 PM Ticket #3089 (Add cascading menus for contex menu intigration) closed by Melba23
Rejected: It seems to me that when clicking on a registered extension the available options should be at the top of the menu, not tucked away in a submenu. M23

Sep 29, 2015:

3:22 PM Ticket #3131 (Add a "safe" modifier to ReDim to preserve Dimensions) closed by Melba23
Rejected: minxomat, As Jon has clearly stated there will be no further Opt flags you can forget that. I not of the opinion that this is something that needs to be "checked" by AutoIt - it must be the responsibility of the coder to do check that any ReDim is correctly written. M23
3:12 PM Ticket #3132 (Version Au3.3.14.2 in Track) closed by Melba23
Fixed
3:00 AM Ticket #3132 (Version Au3.3.14.2 in Track) updated by TicketCleanup
Version changed
Automatic ticket cleanup.
2:38 AM Ticket #3132 (Version Au3.3.14.2 in Track) created by mLipok
Here in track there is lack of this version. Can not be choosen. …

Sep 27, 2015:

6:42 PM Ticket #3091 (_WinAPI_RegQueryValue never returns the buffer size on ERROR_MORE_DATA ...) closed by guinness
Fixed: Fixed by revision [11544] in version: 3.3.15.1
6:34 PM Ticket #3123 (file WinAPIGdi.au3 missing from SCITE editor v3.5.4.0 download) closed by guinness
Works For Me: 3 weeks has elapsed which is plenty of time for you to reply. As you haven't provided a way to replicate this bug report I am closing the ticket. DO NOT REOPEN THIS TICKET, instead go to the forum and explain your problem to the AutoIt users.
6:28 PM Ticket #3120 (Use https://www.ipify.org/ in _GetIP()) closed by guinness
Completed: Added by revision [11542] in version: 3.3.15.1
2:28 AM Ticket #3131 (Add a "safe" modifier to ReDim to preserve Dimensions) updated by minxomat
(1) > Wouldn't this be up to the person writing the script to not do something like this? Well, it's kind of the same deal with constants, where if you try to change a constant, it breaks with an error. (2) An analogy is Visual Basic, where if you ReDim Preserve an array, every other feature remains untouched (such as types). AutoIt's ReDim is preserving by default, but it trashes the old array. That's not an argument, rather a look how this is handled in other languages. ------------------------------ Another (way) less complicated way to do this would be to provide an Opt flag much in the same way as MustDeclareVars. Something along the lines of MustPreserveDimension. Actually, I think this would probably be the better way.
12:46 AM Ticket #3129 (AutoIt Wiki fails to generate tumbnails, PHP Error) closed by Jon
Fixed

Sep 26, 2015:

8:47 PM Ticket #3131 (Add a "safe" modifier to ReDim to preserve Dimensions) updated by BrewManNH
How exactly are you expecting this to work? Are you expecting the script to display an error and exit at this point? That would make it a debugging feature, and debugging features should never be in production code by default. Wouldn't this be up to the person writing the script to not do something like this? I can understand a bit of hand holding, but this is training wheels for bad coders isn't it?
9:52 AM Ticket #3129 (AutoIt Wiki fails to generate tumbnails, PHP Error) updated by TheDcoder
It works now, Thanks for fixing it :)
4:07 AM Ticket #3131 (Add a "safe" modifier to ReDim to preserve Dimensions) created by minxomat
This is a request for a modifying keyword (or alternatively an Opt …
2:09 AM Ticket #3129 (AutoIt Wiki fails to generate tumbnails, PHP Error) updated by BrewManNH
It's working for me now, just tested it and the images are showing.

Sep 25, 2015:

10:33 PM Ticket #3129 (AutoIt Wiki fails to generate tumbnails, PHP Error) updated by Jon
Can you retest please, I've made a tweak.
9:30 PM Ticket #3128 (Pragma Compile Directive inputboxres description change) updated by Melba23
Not quite the wording you suggested but much clearer language M23
9:29 PM Ticket #3128 (Pragma Compile Directive inputboxres description change) closed by Melba23
Fixed: Fixed by revision [11536] in version: 3.3.15.1
9:24 PM Ticket #3130 (Crash since AutoIT3.3.14x on call COM-Object winhttp.winhttprequest.5.1) closed by Melba23
Rejected: In future please use the forum for support questions. And yes there is a difference - 3.3.14.? now crashes on COM errors whereas previous releases silently hid them. I imagine it is this - but posting in the forum will get you more details. M23
9:11 PM Ticket #3130 (Crash since AutoIT3.3.14x on call COM-Object winhttp.winhttprequest.5.1) created by th.edlinger@…
I use following code for doing HTTP-POST-requests: […] The server …
11:43 AM 2015-09-18 20_58_26-.png attached to Ticket #3129 by TheDcoder
Image showing the error
11:43 AM Ticket #3129 (AutoIt Wiki fails to generate tumbnails, PHP Error) created by TheDcoder
Hello, I updated the screenshots of History page in the AutoIt wiki …

Sep 24, 2015:

4:01 PM Ticket #3128 (Pragma Compile Directive inputboxres description change) created by willichan
The description for the inputboxres pragma compile directive is …
3:02 PM Ticket #2915 (Map Memory Leak) updated by Jon
Forwarded from Mars: Replying to Mars (AutoIt.de): > {{{ > Global $Map[], $aArray[1], $Timer = TimerInit() > > While TimerDiff($Timer) < 5000 > $Map.Label = 5 > $aArray[0] = $Map > WEnd > }}} I will explain it: run the script, check taskmanager, see lots of memory consumption. It is impossible to write a script using arrays and maps together. The actual BETA 3.3.15.0 also has this bug.
1:13 PM TracRevisionLog edited by trac
(diff)
1:13 PM WikiPageNames edited by trac
(diff)
1:13 PM TracTimeline edited by trac
(diff)
1:13 PM TracSearch edited by trac
(diff)
1:13 PM TracRoadmap edited by trac
(diff)
1:13 PM RecentChanges edited by trac
(diff)
1:13 PM CamelCase edited by trac
(diff)
1:13 PM TicketQuery created by trac
1:13 PM TracInterfaceCustomization edited by trac
(diff)
1:13 PM TracSupport edited by trac
(diff)
1:13 PM WikiRestructuredText edited by trac
(diff)
1:13 PM TracBatchModify edited by trac
(diff)
1:13 PM PageTemplates edited by trac
(diff)
1:13 PM TracAdmin edited by trac
(diff)
1:13 PM TracUnicode edited by trac
(diff)
1:13 PM TracRss edited by trac
(diff)
1:13 PM WikiHtml edited by trac
(diff)
1:13 PM SandBox edited by trac
(diff)
1:13 PM WikiMacros edited by trac
(diff)
1:13 PM TracIni edited by trac
(diff)
1:13 PM TracFastCgi edited by trac
(diff)
1:13 PM TracInstall edited by trac
(diff)
1:13 PM TracLinks edited by trac
(diff)
1:13 PM TracChangeset edited by trac
(diff)
1:13 PM WikiFormatting edited by trac
(diff)
1:13 PM TracNavigation edited by trac
(diff)
1:13 PM TracAccessibility edited by trac
(diff)
1:13 PM TracGuide edited by trac
(diff)
1:13 PM TracWiki edited by trac
(diff)
1:13 PM TracStandalone edited by trac
(diff)
1:13 PM TracRepositoryAdmin edited by trac
(diff)
1:13 PM TracEnvironment edited by trac
(diff)
1:13 PM InterWiki edited by trac
(diff)
1:13 PM WikiRestructuredTextLinks edited by trac
(diff)
1:13 PM TracQuery edited by trac
(diff)
1:13 PM TracNotification edited by trac
(diff)
1:13 PM WikiNewPage edited by trac
(diff)
1:13 PM TracImport edited by trac
(diff)
1:13 PM TracPermissions edited by trac
(diff)
1:13 PM TracReports edited by trac
(diff)
1:13 PM TracSyntaxColoring edited by trac
(diff)
1:13 PM TracTickets edited by trac
(diff)
1:13 PM TracWorkflow edited by trac
(diff)
1:13 PM TracBrowser edited by trac
(diff)
1:13 PM TracTicketsCustomFields edited by trac
(diff)
1:13 PM WikiProcessors edited by trac
(diff)
1:13 PM TracModWSGI edited by trac
(diff)
1:13 PM WikiDeletePage edited by trac
(diff)
1:13 PM TracPlugins edited by trac
(diff)
1:13 PM TracFineGrainedPermissions edited by trac
(diff)
1:13 PM TracBackup edited by trac
(diff)
1:13 PM TracLogging edited by trac
(diff)
1:13 PM TracUpgrade edited by trac
(diff)
1:13 PM TracChangeLog created by trac
1:13 PM TitleIndex edited by trac
(diff)
1:13 PM TracModPython edited by trac
(diff)
1:13 PM TracCgi edited by trac
(diff)
1:13 PM InterTrac edited by trac
(diff)

Sep 22, 2015:

7:43 PM Ticket #3127 (PixelGetColor ignore third HWND parameter) updated by petrsum@…
I have checked a behavior with "PixelCoordMode" option equal to 2. GetDC WinAPI function that is called before GetPixel still receive a NULL as input parameter. It is strange why processing of the HWND parameter should be tied with "PixelCoordMode" option. Expected result of the passing HWND parameter is possibility of getting a pixel color from an overlapped window.

Sep 20, 2015:

12:18 AM Ticket #3127 (PixelGetColor ignore third HWND parameter) updated by anonymous
HWND used only if "PixelCoordMode" 0 or 2. If 1 then HWND is ignored. So it was always.

Sep 19, 2015:

8:08 PM Ticket #3127 (PixelGetColor ignore third HWND parameter) updated by anonymous
Perhaps, this bug causes a strange behavior of the PixelCoordMode option switching. Now it seems that the default (absolute screen coordinates) mode is used always.
8:00 PM api-get-pixel.png attached to Ticket #3127 by petrsum@…
Screen-shoot of the PixelGetColor function call
7:59 PM Ticket #3127 (PixelGetColor ignore third HWND parameter) created by petrsum@…
The PixelGetColor function with passed HWND parameter should analyze a …

Sep 18, 2015:

2:26 AM Ticket #2768 (Error: missing separator character before keyword.) updated by anonymous
There's been a new release version put out, the updated Au3Check is included with it.
Note: See TracTimeline for information about the timeline view.