Timeline



Dec 14, 2011:

10:22 PM Ticket #2063 (site's search won't take keywords with less than 3 chars) closed by Valik
No Bug
9:37 AM Ticket #2063 (site's search won't take keywords with less than 3 chars) updated by AdmiralAlkex
There's no problem with the search engine. What's wrong with the download on the download page? http://www.autoitscript.com/site/autoit/downloads/ If you read past the first couple of lines you would see: ---- AutoIt Previous Versions – v3.2.12.1 was the last version that was compatible with Windows 95 and Windows NT 4.0. ---- Right next to the link to 3.2.12.1
8:10 AM Ticket #2068 (ACos() bug) created by Spiff59
The x86 version of the ACos() function seems to go south after six …

Dec 13, 2011:

5:04 PM Ticket #2066 (bad dllStructSetData return for int) updated by J-Paul Mesnage
In fact long, bool are alias of int for unsigned 32-bit type as they cannot be stored without lost of precision the int64 is returned. This apply to wparam whish is unsigned *_ptr does not mean ptr but ptr size so when solving for int […] this will change under x64 as ptr will are 64-bit
4:35 PM Ticket #2067 ($n=-2147483648 is not an int32) created by J-Paul Mesnage
such value can be stored in an int32 but is stored in an int64 […] …
4:19 PM Ticket #2066 (bad dllStructSetData return for int) updated by jchd
More unexpected readback types running .23 beta on x86. […]
1:34 PM Ticket #2066 (bad dllStructSetData return for int) updated by J-Paul Mesnage
Description changed
1:33 PM Ticket #2066 (bad dllStructSetData return for int) created by J-Paul Mesnage
running the following script show a little discrepancy of a int64 …
12:15 PM Ticket #1870 (@GUI_DRAGFILE) updated by guinness
A 'workaround' is using StringTrimRight and StringLen […]

Dec 12, 2011:

11:41 PM Milestone 3.3.7.23 completed
4:41 PM Ticket #2064 (DriveStatus returns INVALID on existing path (by Volume Name)) updated by J-Paul Mesnage
I think DriveStatus must work as DriveGetType which does not care of the extended syntax
1:00 PM Ticket #2064 (DriveStatus returns INVALID on existing path (by Volume Name)) closed by trancexx
No Bug: The change is introduced in v3.3.7.2 with revision [5991]. Change log entry is: Fixed #1860: DriveStatus Returns Ready with blank value. The description for the function is that it takes path of drive to receive information from as parameter, not a volume GUID path. The fact that something undocumented worked before doesn't make it a bug when no longer does. Therefore this is not a bug.
12:31 PM Ticket #2065 (how to detect which button clicked in internet Explorer using java script) closed by trancexx
No Bug
12:09 PM Ticket #2065 (how to detect which button clicked in internet Explorer using java script) updated by anonymous
This is not a forum
12:08 PM Ticket #2065 (how to detect which button clicked in internet Explorer using java script) created by manishpatel810@…
how to detect which button clicked in internet Explorer using java …
2:39 AM Ticket #2064 (DriveStatus returns INVALID on existing path (by Volume Name)) created by MrCreatoR <mscreator@…>
Run this on 3.3.7.1 and lower versions: […] The result is fine, …
12:58 AM Ticket #2063 (site's search won't take keywords with less than 3 chars) created by jmichae3@…
this is a problem with the site's search engine. some windows OSs …

Dec 9, 2011:

9:00 PM Ticket #1658 (COM / OLE object access causes error code 80020003 - member not found) updated by TicketCleanup
Version, Milestone changed
Automatic ticket cleanup.
7:21 PM Ticket #1658 (COM / OLE object access causes error code 80020003 - member not found) closed by trancexx
Fixed: Great, closing then. Fixed by revision [6475] in version: 3.3.7.22

Dec 8, 2011:

10:12 PM Ticket #2050 (Handle should bei called filehandle) updated by guinness
Resolution, Milestone changed
Fixed by revision [6508] in version: 3.3.7.23
7:18 PM Ticket #2050 (Handle should bei called filehandle) updated by Tweaky
In version 3.3.7.22 it is not yet corrected
6:36 PM Ticket #1658 (COM / OLE object access causes error code 80020003 - member not found) updated by MeJonah@…
Yep, it is fixed. You guys are awesome, especially considering I was never able to get you the CR runtime to test with.
8:58 AM Ticket #2062 (Example text _IEFormElementGetCollection) created by MvL
Last time I tried (Windows XP, 3.3.6.1 and 3.3.7.22) the index of the …

Dec 7, 2011:

6:25 PM Milestone 3.3.7.22 completed
6:06 PM Ticket #2003 (ProcessWaitClose() using too much CPU) updated by Valik
Severity changed
Blocking flag removed. Fixing this requires changes that I do not feel comfortable making for the next release.

Dec 5, 2011:

12:37 PM Ticket #1802 (_WinAPI_CallWindowProc() and _WinAPI_DefWindowProc() are not Unicode ...) updated by trancexx
And they should. There are some special functions that should be supported by standard UDFs in both versions. These functions are examples of that. You are free to ask for SVN access and after that be part of UDF development if you wish.

Dec 4, 2011:

8:30 PM Ticket #1802 (_WinAPI_CallWindowProc() and _WinAPI_DefWindowProc() are not Unicode ...) updated by Yashied
All functions that are in WinAPI.au3 uses the Unicode version, apart from these two.

Dec 3, 2011:

8:15 PM Ticket #1658 (COM / OLE object access causes error code 80020003 - member not found) updated by trancexx
This should be fixed with the next beta (3.3.7.22). Please test if you know how. I will close this ticket soon as fixed unless somebody proves it still exists.

Dec 2, 2011:

11:42 PM Ticket #2042 (Windows 8 support for @OS macros) closed by Valik
Completed: Added by revision [6473] in version: 3.3.7.22
11:10 PM Ticket #2061 (Rewrite OS_Version class) created by Valik
The code is an unwieldy mess of madness. It needs refactored so that …

Nov 30, 2011:

10:24 PM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by Shaggi
Replying to anonymous: > AFAIR, it's a known bug in SciTE, when the script is runing already and we use SciTE function that runs other tool, second copy of the script is executed. > > Try to run the script from SciTE and press F1. That would be it.
6:10 PM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) closed by Valik
Wont Fix: Regardless of what the root cause of this issue is, this is a SciTE bug. SciTE is not our project.
11:22 AM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by anonymous
AFAIR, it's a known bug in SciTE, when the script is runing already and we use SciTE function that runs other tool, second copy of the script is executed. Try to run the script from SciTE and press F1.

Nov 29, 2011:

3:45 PM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by anonymous
Using scite 2.27, downloaded here: http://www.autoitscript.com/site/autoit-script-editor/downloads/ Windows 7 x64, happens on any version of autoit (beta and release), had the problem for a long time. AutoIt3Wrapper v.2.0.3.0 Environment(Language:0406 Keyboard:00000406 OS:WIN_7/ CPU:X64 OS:X64) - in case it matters.
8:29 AM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by J-Paul Mesnage
Replying to Shaggi: > Not much to say, sometimes, like 40% of times when i use ALT+I on a include line it runs the script. Very annoying sometimes. > Using the full scite4autoit. > > Couldn't find any other ticket after some searching, dno if it has been reported before.. You better describe which envirnonment you are running with, just copy the "SciTE Output plane" content. It is at least needed to understand what is going on.
7:54 AM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) updated by guinness
Started discussion in the SciTE4AutoIt3 thread >> http://www.autoitscript.com/forum/topic/130437-new-scite4autoit3-available-with-scite-v227/page__view__findpost__p__942915
7:28 AM Ticket #2060 (UDFs Documentation issues) closed by guinness
Fixed: Fixed by revision [6462] in version: 3.3.7.22
12:33 AM Ticket #2060 (UDFs Documentation issues) updated by MrCreatoR <mscreator@…>
Oops, here is a correction for the first issue: >There should be a remark about the fact that it will work only if $LVS_SINGLESEL style not used.
12:28 AM Ticket #2060 (UDFs Documentation issues) created by MrCreatoR <mscreator@…>
While translating AutoIt help file by the Russian community, we found …

Nov 28, 2011:

9:18 PM Ticket #2059 (Open include (Alt+i) runs scripts, sometimes.) created by Shaggi
Not much to say, sometimes, like 40% of times when i use ALT+I on a …

Nov 27, 2011:

11:34 PM Ticket #1973 (_IEAttach failes and crashes on some special window constellations) closed by trancexx
No Bug: This is not bug and that's not solution. Create and use COM error handler to avoid situations like that.
11:25 PM Ticket #2034 (_GUICtrlMenu_AppendMenu - bug when BitOr($MF_BYPOSITION, $MF_STRING) ...) closed by trancexx
Fixed: Fixed by revision [6454] in version: 3.3.7.22
5:30 PM Ticket #1802 (_WinAPI_CallWindowProc() and _WinAPI_DefWindowProc() are not Unicode ...) closed by trancexx
No Bug: Yashied you have registered a window class using Unicode version of that function. In that case the system passes text parameters of messages as Unicode, meaning your _MyWndProc() must use Unicode version functions you use. If you have done opposite of that _MyWndProc() would be correct. This proves that functions inside WinApi.au3 are not wrong. What's true is that WinApi.au3 misses Unicode versions of those functions as DllCall function calls ANSI versions of functions by default when there are any doubts. This is not a bug.

Nov 26, 2011:

12:55 PM Ticket #1900 (Improvements for StringRegExpGUI) updated by Zedna
@FichteFoll Community appreciate it but not as part of standard Autoit package. This Trac is designated only for things related to standard Autoit package. Please create topic with this your improved/fixed version of StringRegExpGUI in Examples section on forum.
8:56 AM Ticket #1900 (Improvements for StringRegExpGUI) closed by trancexx
Rejected: The need for this script is questionable. Apparently community doesn't appreciate it enough.

Nov 25, 2011:

6:00 PM Ticket #1770 (Script getting pause when popup appears in IE) updated by TicketCleanup
Milestone changed
Automatic ticket cleanup.
5:53 PM Ticket #2055 (Convert UDF's to struct* type) closed by AdmiralAlkex
Fixed: Fixed by revision [6445] in version: 3.3.7.22
4:29 PM Ticket #1770 (Script getting pause when popup appears in IE) closed by J-Paul Mesnage
No Bug
4:29 PM Ticket #1770 (Script getting pause when popup appears in IE) reopened by J-Paul Mesnage
4:11 AM Ticket #1472 (GUISetCursor Bug) updated by Valik
Umm. No. The last time we tried to fix the idiocy that pertains to this Jon made comment:1. There's no way in hell I'm going to try again to fix it at the 11th hour. What needs to happen is a script breaking change needs to occur to normalize the values of MouseGetCursor() and GUISetCursor().
12:34 AM Ticket #1472 (GUISetCursor Bug) updated by Zedna
Just clarification for developers: Here is related ticket which is cause of this bug: MouseGetCursor() - identify also standard hand cursor (IDC_HAND) http://www.autoitscript.com/trac/autoit/ticket/1311 I think this ticket should be set as Blocking.

Nov 24, 2011:

9:00 PM Ticket #1777 (Issues with Security.au3) updated by TicketCleanup
Milestone changed
Automatic ticket cleanup.
7:24 PM Ticket #1777 (Issues with Security.au3) closed by trancexx
Fixed
7:05 PM Ticket #1770 (Script getting pause when popup appears in IE) updated by trancexx
Owner, Resolution, Milestone changed
Nothing changed here. I specified wrong bug id that resulted in raising this one. Error on my side.

Nov 23, 2011:

9:50 AM Ticket #2041 (_FTP_ListToArrayEx Datetime Format) closed by J-Paul Mesnage
Duplicate: Replying to anonymous: > A few additional inforamtion: > > In the help file it says that with $b_Fmt=1 the format will be YYYY/MM/DD and with $b_Fmt=0 it will be MM/DD/YYYY. > > But as seen on the picture the output with $b_Fmt=1 is YYYY/DD/MM, so defnetly a bug. check with beta as it as been solved by #1509

Nov 22, 2011:

6:58 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by wraithdu
Not a problem, thank you for the response. Would it be reasonable to make a smaller change, and have DirCreate return an error when given a path greater than the buffer size, instead of returning success and creating some unknown truncated path? It's this latter behavior that should ideally be avoided.
3:00 PM Ticket #2057 (Advanced Window Descriptions - Add "PID" Property) updated by TicketCleanup
Version changed
Automatic ticket cleanup.
12:54 PM Ticket #2058 (WinWait, WinWaitActive and WinActive calls are waiting indefinitely ...) created by Math
Few AutoItX functions are hanging when using in VS 2008(vb.net) IDE. …
12:41 PM Ticket #2057 (Advanced Window Descriptions - Add "PID" Property) created by firelion_84@…
Would be be possible to add "PID" as a property recognised in the …
12:38 AM Ticket #269 (ImageSearch()) updated by trancexx
No offense taken. You should be able to see reddish box above the text area for reply. Read what it says and try to follow those guidelines. Thanks.

Nov 21, 2011:

10:50 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by Valik
JPM, you are not a developer any longer, please stop acting like one. Yes, JP brought it to our attention that long paths are not supported. All path related functions use a hard-coded buffer length of MAX_PATH. I detest hard-coded buffer sizes and I know that it needs changed to support variable length paths. The problem is I'm trying to get a release out before we all die and we can't make significant changes like this just weeks before said release. It was fine to create the ticket but all this discussion with JP has been pointless. Long paths will be supported at some point after the next release and this ticket should be irrelevant at that time.
9:10 PM Ticket #269 (ImageSearch()) updated by Zedna
Replying to Zedna: > Replying to trancexx: > > After weighting gains and losses this ends up rejected. > > I'm very interested in these positive/negative arguments ... No offence, just be more detailed when closing tickets please, thanks.
8:13 PM Ticket #1658 (COM / OLE object access causes error code 80020003 - member not found) updated by MeJonah@…
I am attempting to come up with something, and will post it soon.
4:49 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by J-Paul Mesnage
Replying to wraithdu: > So you're confirming this is an error/bug as to the behavior of DirCreate? Because DirCreate, as I showed, is not creating the extra long path properly. > > If so, thank you :) Before your ticket I already warn the other dev that we may have to support […] Perhaps they will do something. I am a banned Dev Thanks to Valik
4:43 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by wraithdu
So you're confirming this is an error/bug as to the behavior of DirCreate? Because DirCreate, as I showed, is not creating the extra long path properly. If so, thank you :)
4:27 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by J-Paul Mesnage
I understand, I can add that the removal is only possible if the full path of the last created directory if less than ~260 chars. Explorer itself cannot remove it (I am running Win7 Sp1 32-bit)
3:03 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by wraithdu
That's not correct. The directory is not created properly. *A* directory *is* created, but it's not the one specified in the function. The path is truncated to 255 chars and a 255 char length directory is created. In fact FileExists does work correctly on paths longer than 255 chars, but you have to create them via other means to test this. Here is the path from your test as it was created: C:\some\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\really\lo It is 255 chars long. Try this for comparison. You'll have to rename some directories to remove the final path since it will be too long (>255). […]
2:26 PM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) updated by J-Paul Mesnage
In fact the dir is created when using […] the only thing you can perhaps contest is FileExists or DirRemove does not found such path […]
11:44 AM Ticket #2056 (Excel.au3 - 5 Broken Functions) updated by Aru
Windows 7, Excel 2010
11:16 AM Ticket #2056 (Excel.au3 - 5 Broken Functions) created by Aru
3.3.7.21(beta) 3.3.6.1 Any reference to …
3:43 AM Ticket #2055 (Convert UDF's to struct* type) created by AdmiralAlkex
Just a reminder for myself.
2:51 AM Ticket #2054 (DirCreate incorrectly reports success when path is longer than 255 chars) created by wraithdu
DirCreate returns 1 (success) when the path is longer than 255 …

Nov 20, 2011:

11:56 PM Ticket #269 (ImageSearch()) updated by Zedna
Replying to trancexx: > After weighting gains and losses this ends up rejected. I'm very interested in these positive/negative arguments …
9:51 AM Ticket #1953 (FileExists returns 1 for non existing path) updated by trancexx
Quick code review indicates that there could be problems with FileGetTime and related functions. Additional problem seems to be file system redirector.
9:28 AM Ticket #262 (Plugins - array parameters) closed by trancexx
Rejected: Current implementation of "Plugin" feature and internal handling of array data type makes the request not worthy of the complexity that would be the result of having this feature. However plugins would be handled eventually one way or the other. When that happens this ticket would be rendered invalid simply because plugins require thorough evaluation that should address every aspect of the implementation including array support.
8:05 AM Ticket #488 (ObjGet() needs an instance parameter) updated by trancexx
Owner, Status changed

Nov 19, 2011:

2:14 PM Ticket #1698 (GUICtrlSetLimit, limit 32767) updated by Emiel Wieldraaijer
The following also does not work $1 = GUICtrlCreateInput("3389", 235, 200, 150, 20) $2 = GUICtrlCreateUpdown($1, $UDS_NOTHOUSANDS) GUICtrlSetLimit($2, 49151, 1024)

Nov 18, 2011:

2:43 PM Ticket #269 (ImageSearch()) closed by trancexx
Rejected: After weighting gains and losses this ends up rejected.
Note: See TracTimeline for information about the timeline view.