Timeline
Aug 13, 2013:
- 1:38 PM Ticket #2336 (Blockinput (1) not for WACOM Pen with Win8) closed by
- Rejected
- 1:37 PM Ticket #2336 (Blockinput (1) not for WACOM Pen with Win8) updated by
- This function is just a wrapper from a WinApi call. We won't be adding anything else in this area.
- 10:45 AM Ticket #2366 (For loop not working as expected) closed by
- Fixed: Fixed by revision [8491] in version: 3.3.9.17
- 9:00 AM WikiStart edited by
- Update version info. (diff)
Aug 10, 2013:
- 10:50 AM Milestone 3.3.9.16 completed
- 8:52 AM Ticket #2379 (WS_EX_LAYOUTRTL and GUICtrlCreateMenu causes bug) updated by
- forgot to mention it .. but this problems did not occur in version 3.3.6.1
- 8:41 AM Ticket #2379 (WS_EX_LAYOUTRTL and GUICtrlCreateMenu causes bug) updated by
- @BrewManNH You are right i do not use GUICtrlCreateTabItem("") .. never used it .. and it's mentioned in the help files .. it solves the problem of the missing button.. Indeed the menu item at the end of the script solves the problem .. but it's still a bug. the code or the help files should change.. Thanks
Aug 9, 2013:
- 11:29 PM Ticket #2380 (Add _IsDir) updated by
- After a lengthy discussion, I went with adding it as an example only.
- 11:21 PM Ticket #2380 (Add _IsDir) closed by
- Completed: Added by revision [8433] in version: 3.3.9.16
- 2:04 PM Ticket #2380 (Add _IsDir) updated by
- I think it would be best suited as a second/third example for FileGetAttrib. But I will ask my peers what they think as well.
- 2:00 PM Ticket #2380 (Add _IsDir) updated by
-
Version changed
Automatic ticket cleanup. - 1:16 PM Ticket #2380 (Add _IsDir) created by
- Often used. […]
Aug 8, 2013:
- 7:57 PM Ticket #2379 (WS_EX_LAYOUTRTL and GUICtrlCreateMenu causes bug) updated by
- If you move the CreateMenu item to the end of the list of things being created, it doesn't cause the problems. Also, you never close the tab item creation by using "GUICtrlCreateTabItem("")" after the last tab item created, which might be causing part of your problem.
- 7:16 AM Ticket #1024 (GUICtrlSetTip for tabitems sets incorrectly in certain situations) closed by
- Fixed: Fixed by revision [8426] in version: 3.3.9.16
- 7:14 AM Ticket #1024 (GUICtrlSetTip for tabitems sets incorrectly in certain situations) reopened by
Aug 7, 2013:
- 7:42 PM Ticket #2379 (WS_EX_LAYOUTRTL and GUICtrlCreateMenu causes bug) created by
- Hi, I reported this bug 16 months ago (Ticket 2167) but Jon rejected …
- 11:56 AM Ticket #2378 (BITMAPV4HEADER and BITMAPV5HEADER Structures incorrect) closed by
- Fixed: Fixed by revision [8418] in version: 3.3.9.16
- 7:35 AM Ticket #2370 (StringReplace & StringRegExpReplace Add Offset\The starting position ...) updated by
- […]
- 7:23 AM Ticket #2370 (StringReplace & StringRegExpReplace Add Offset\The starting position ...) updated by
- Yes, I always use the latest Beta, where I noticed that StringRegExpReplace has been improved a lot about the speed in the Case-sensitivity Mod, however have a flag "Offset\The starting position of the search" in StringReplace or in StringRegExpReplace, as in StringInStr and StringMid that working really fast, would be really helpful Ciao.
- 12:27 AM Ticket #2378 (BITMAPV4HEADER and BITMAPV5HEADER Structures incorrect) created by
- In the <WinAPIGdi.au3> header the definitions for BITMAPV4HEADER and …
Aug 6, 2013:
- 1:55 PM Ticket #2355 (Custom compiler) closed by
- Rejected
- 1:55 PM Ticket #2355 (Custom compiler) reopened by
- 10:29 AM Ticket #2355 (Custom compiler) closed by
- No Bug
- 10:18 AM Ticket #2370 (StringReplace & StringRegExpReplace Add Offset\The starting position ...) updated by
- DXRW4E, are you using the latest beta? The regex compiler that AutoIt uses has been updated. Can you give that a go please?
- 10:06 AM Ticket #2373 (@ScriptDir returns trailing slash) closed by
- Fixed: I've updated this in the documentation. I don't know when it'll be included but it's done.
- 9:47 AM Ticket #2367 (beta regression on retrieving twice same $oIE.document) updated by
- Still buggy under X64 see this http://www.autoitscript.com/forum/topic/153009-autoit-v33913-beta/?p=1099859 definitly not a regression still old bug
- 9:33 AM Ticket #2371 (_PathSplit with relative Paths) updated by
-
Component changed
Aug 4, 2013:
- 10:30 PM Milestone 3.3.9.15 completed
- 2:09 PM Ticket #2376 (Function fails to return a value properly) updated by
- Replying to guinness: This fixed it, thanks.
Aug 3, 2013:
- 10:03 PM Ticket #2377 (Crypt(Un)ProtectData if Crypt.au3 UDF) closed by
- Rejected
- 10:01 PM Ticket #2376 (Function fails to return a value properly) closed by
- Works For Me
- 9:57 PM Ticket #2377 (Crypt(Un)ProtectData if Crypt.au3 UDF) updated by
- Please re-read the feature request guidelines again.
- 8:00 PM Ticket #2377 (Crypt(Un)ProtectData if Crypt.au3 UDF) updated by
-
Version changed
Automatic ticket cleanup. - 7:26 PM Ticket #2377 (Crypt(Un)ProtectData if Crypt.au3 UDF) created by
- I think the title is straight forward! Why not implementing …
Aug 2, 2013:
- 4:03 PM Milestone 3.3.9.14 completed
- 3:15 PM Ticket #2376 (Function fails to return a value properly) updated by
- Did you try with v3.3.9.13? As there was an issue with _WinAPI_GUIDFromString that I fixed.
- 12:53 PM Ticket #2376 (Function fails to return a value properly) created by
- The following block of code works perfectly fine in the release …
- 12:00 AM Ticket #347 (Add _WinAPI_SetFilePointer) updated by
-
Version, Milestone changed
Automatic ticket cleanup.
Aug 1, 2013:
- 11:00 PM Ticket #272 (_FileListArrayEx() - with recursive option) updated by
-
Version, Milestone changed
Automatic ticket cleanup. - 10:50 PM Ticket #347 (Add _WinAPI_SetFilePointer) updated by
- This is available in WinAPI.au3.
- 10:49 PM Ticket #347 (Add _WinAPI_SetFilePointer) updated by
-
Version, Milestone changed
- 10:48 PM Ticket #272 (_FileListArrayEx() - with recursive option) updated by
- This has been added with the function name of _FileListToArrayRec in File.au3.
- 10:48 PM Ticket #272 (_FileListArrayEx() - with recursive option) updated by
-
Version, Milestone changed
- 1:08 PM Ticket #2369 (.exe is not working in driver) closed by
- No Bug
- 10:45 AM Ticket #2374 (Incorrect return values for up to 4 UDFs) closed by
- Fixed: Fixed by revision [8312] in version: 3.3.9.14
- 8:18 AM Ticket #2374 (Incorrect return values for up to 4 UDFs) updated by
- I have moved the discussion to the help issues thread for clarification, as lines numbers aren't matching up either.
- 8:10 AM Ticket #2374 (Incorrect return values for up to 4 UDFs) updated by
- Beta Version 3.3.9.13
- 7:47 AM Ticket #2374 (Incorrect return values for up to 4 UDFs) updated by
- Which beta version are you using please?
- 4:10 AM Ticket #2375 (Change default return value for SetError and SetExtended) created by
- Functions default to a 0 return value. Use of SetError or SetExtended …
- 3:33 AM Ticket #2374 (Incorrect return values for up to 4 UDFs) created by
- I have done a quick review of usage of SetError and SetExtended in the …
Jul 31, 2013:
- 9:15 PM Ticket #2373 (@ScriptDir returns trailing slash) updated by
- Definety we must update the doc for root because FileChangeDir(@ScriptDir) for a script located on root
- 7:54 AM Ticket #2373 (@ScriptDir returns trailing slash) updated by
- Looks like JP changed it after this discussion: http://www.autoitscript.com/forum/index.php?s=&showtopic=35346&view=findpost&p=259052
- 6:26 AM Ticket #2373 (@ScriptDir returns trailing slash) updated by
- This is intentional and was changed back in: 19th December, 2006 - v3.2.2.0 Fixed: @ScriptDir equal @WorkingDir for rootdir (x:\).
- 6:22 AM Ticket #2371 (_PathSplit with relative Paths) closed by
- Fixed: Fixed by revision [8265] in version: 3.3.9.14
Jul 30, 2013:
- 4:30 PM Ticket #2373 (@ScriptDir returns trailing slash) updated by
- Only happens when the script is located in the root of a drive. Wraithdu and JLogan3o13 pointed this out. .
- 4:20 PM Ticket #2373 (@ScriptDir returns trailing slash) created by
- @ScriptDir is returning a trailing slash for me, consistently, on the …
- 10:38 AM Ticket #2372 (Function incorrect number of parameters error on wrong line) created by
- It is reporting the location of where another function was defined, …
- 12:00 AM Ticket #2371 (_PathSplit with relative Paths) updated by
-
Version changed
Automatic ticket cleanup.
Jul 29, 2013:
- 11:07 PM Ticket #2371 (_PathSplit with relative Paths) updated by
- Note: the returned array contains the correct data.
- 11:05 PM Ticket #2371 (_PathSplit with relative Paths) created by
- I believe this started in 3.3.9.8, but it is present in 3.3.9.13. …
- 12:27 PM Ticket #2355 (Custom compiler) updated by
- Jon my intention is not to offend anyone, I have much respect for people like you and for your hard work, i can only envy your knowledge. Do you want to know why i have say "noone cares"? Because on the forum we can't talk about security of our script, closed in a blink of an eye follow the rule DADT, officially because we can't talk about decompiling, but the subject is not the opposite, so prevent decompiling? ;) I'm totally agree about epidemic 200 threads with the same subject, but maybe can be opened by you or one of the stuff an official thread about "suggestion" or proposal-script for improve the security of our exe? If you "don't have the skills", maybe other has ( not me :D ) Said this, i think you know the new beta is incompatible with the decompiling tools, because you have change the something in the compiling part which makes the executable not recognized, don't know if it is involved the resource part. Many people say this is only a temporary phase. By this I was inspired by the idea of "custom compiler", if the compile process "change everytime" in some random part then the exe can be decompiled only manually. A good article i have found about security of executable is this, maybe you are interested: http://en.wikipedia.org/wiki/Portable_Executable_Automatic_Protection
Jul 28, 2013:
- 9:04 PM Ticket #2339 (IsAdmin() and Sandboxie) updated by
- Actually I've changed IsAdmin() in beta 3.3.9.14 - try again.
- 7:59 PM Ticket #2355 (Custom compiler) updated by
- I'm fairly insulted to be told "noone cares". If it were possible to improve the compilation I would. I just don't have the skills and I've wasted weeks of my life trying. In fact I believe it to be close to, if not actually impossible with the current interpreter+compiled script way that is used. Nothing apart from a full rewrite of autoit will do. Do you know how the current best decompiler works? It doesn't even read in the script and trying and work out how I encoded and encrypted and obfuscated things. It doesn't even bother. What it does is it lets the script run and then as it executes it always gets to a point where it has to "run" the line of script - at that point the script tokens (not even stored as text) are ripped out of memory and reversed into readable text. No amount of tweaking will stop that. .NET can be one-click decompiled in a similar fashion. On the plus side with the new beta scripts are stored as part of the resources in an exe rather than hacked-onto the end. This means that it may be possible to use your own packer/exe protector type software to wrap around it. I've not tried myself though.
- 12:05 PM Ticket #2370 (StringReplace & StringRegExpReplace Add Offset\The starting position ...) updated by
- sorry, post by mistake it seems that in StringInStr works really well and quickly, instead StringRegExp does not work well in almost as if it does not work at all […] Ciao.
- 12:00 PM Ticket #2370 (StringReplace & StringRegExpReplace Add Offset\The starting position ...) updated by
-
Version changed
Automatic ticket cleanup. - 11:58 AM Ticket #2370 (StringReplace & StringRegExpReplace Add Offset\The starting position ...) created by
- would be very useful to add the "Offset\The starting position of the …
- 11:51 AM Ticket #2369 (.exe is not working in driver) updated by
- Before submitting a ticket Just go to the forum to get help. If you are sure it can be a bug just attach everything needed to repro Try to isolated, without outside AutoIt stuff if possible. We can fix only if we can reproduce.
- 11:31 AM Ticket #2355 (Custom compiler) updated by
- Melba, I don't need and i don't want open another thread ( the last was closed, you know so i'm not do it again ) or make another Feature Request. I'm not flogged this subject to death, but seems noone cares ( in Dev's group ) if you exe can be decompiled is so easy way by few click, not by "people with the time and determination to break into whatever they wish", but by anyone with at least a finger, a mouse, no knowledge and a internet connection. The only subject of this Feature request is "try" to found something can be userful for improve our exe, if a custom compiler, a dynamic stub, a password protected .exe or any idea can be helpful for the security or our script. I'll remember you ( I know you know ;) ) the Autoit EULA can't allow to us to edit the .exe after the compilation, disassemble, edit or modify the stub etc. without breaking the EULA so only from the "high plan" can release something in this way
Jul 27, 2013:
- 4:10 PM Ticket #2369 (.exe is not working in driver) created by
- I working on selenium wecdriver. Scenario, when i press print button. …
- 1:18 PM Ticket #2355 (Custom compiler) updated by
- Terenz, The last time Jon changed the compilation method it was only a matter of hours before a new decompiler appeared. There are people out there with the time and determination to break into whatever they wish - as games and OSs get hacked pretty quickly despite huge sums being spent on prevention, what hope do we have with a simple scripting language? Basically if you want security then do not use AutoIt - or in fact any other language. Do as Mat has suggested and go down a different road. ;) And you have now flogged this subject to death. I will take a very dim view of any more threads, posts or tickets from you about AutoIt code security - please let it drop. M23
- 12:12 PM Milestone 3.3.9.13 completed
- 11:26 AM Ticket #2367 (beta regression on retrieving twice same $oIE.document) closed by
- Fixed: Fixed by revision [8187] in version: 3.3.9.13
- 10:40 AM Ticket #2367 (beta regression on retrieving twice same $oIE.document) updated by
- This seems to have been broken in revision 6130,6259 which is when we started to be more clever if typeinfo was available. It's hard to repo and I can only repo it at by running the x64 version of AutoIt in release mode. Note, this is actually around the time of 3.3.8.0
Jul 26, 2013:
- 11:58 PM Ticket #1667 (WinMove, Child-Window, Default.) updated by
-
Owner, Resolution, Milestone changed
Fixed by revision [8179] in version: 3.3.9.13 - 6:52 PM Ticket #2075 (GUICtrlSetImage changes icon position on resizable window) closed by
- Fixed: Fixed by revision [8175] in version: 3.3.9.13
- 3:00 PM Ticket #2336 (Blockinput (1) not for WACOM Pen with Win8) updated by
-
Version changed
Automatic ticket cleanup. - 2:36 PM Ticket #2336 (Blockinput (1) not for WACOM Pen with Win8) updated by
-
Type changed
change to Feature request as it is a new input device not supported - 2:33 PM Ticket #2339 (IsAdmin() and Sandboxie) closed by
- Rejected: this ticket has been closed for lack of documentation
Jul 25, 2013:
- 12:52 PM Ticket #2355 (Custom compiler) updated by
- From your answers guys i think i wasn't clear so i'll repeat again: If a XYZ hacker want to decompile an ABC autoit exe, there is NOTHING you can do. I know, in every language the situation is always the same, is "normal" and you have to live with it. But for autoit the situation is: If a XZY noob, lamer, without any debugging-reverse-assembly knowledge what to decompile a ABC autoit exe, he can do it in a few click with automatic tools ( not one, but three-four ), doesn't matter the Func() you use, if you obfuscate it, packed or other protection i have write in the third post. This isn't a security issue? Pratically is a open door and everyone can go in. So, for the last situation and only for the last situation, are you totally sure the dev's can do nothing? Would you put your hand on fire?
- 3:04 AM Ticket #2368 (Inconsistent GUICreate results) created by
- GUICreate produces a window with sizes dependent on the style used. I …
Jul 24, 2013:
- 11:37 PM Ticket #2355 (Custom compiler) updated by
- Well the truth is: "There is nothing to do, sorry". There is no way to compile a script so that the interpreter can run it but it can't be decompiled. If security is an issue then move the code to a web server and create a web interface for it, that's security by design, rather than "security" by obscurity.
- 7:35 PM Milestone 3.3.9.12 completed
- 11:20 AM Ticket #2367 (beta regression on retrieving twice same $oIE.document) created by
- The repro script is returning now 1 instead of 0 […]
Jul 23, 2013:
- 8:41 PM Ticket #2108 (_Singleton leaves an open handle) updated by
- The point raised (and solution provided) by smartee was (now implemented in misc.au3) was valid. I'm quite sure he understood the function of _Singleton(), and - more importantly - it would seem that he had run into the fact that _Singleton() sometimes just-doesn't-work as_documented. As a matter of fact, _Singleton() was badly broken when "The whole point of the singleton pattern is to ensure that one and only one instance of the object (In this case the script) exists at a time." That may have been Valik's intent when he created _Singleton(), but that is certainly not how his code ever worked. To begin with, _Singleton() did not (and still does not) create a "Global\*" mutex by default. So, as it stood (and still stands even in smartee's version), _Singleton() only worked when the session was also the same. "Pattern" broken, claim to "ensure that one and only one instance of the object" exists couldn't be upheld. Then, Valik let CreateMutex() default the security attribute. So, _Singleton() only worked when the user was also the same. Again, "pattern" broken, claim to "ensure that one and only one instance of the object" exists couldn't be upheld. Then there was the fact that _Singleton() gave the caller the option of returning from the call. Valik's original function Exit()ed, but that is just plain bad design to begin with. Not only does it not provide the caller with the option of notifying the user of the condition, or switching to the other window, or whatever, but it also cuts off any chance of passing back an unexpected error condition that the caller should have to deal with. For example, an invalid name as parameter (e.g. containing slashes). Then, by not closing the handle upon ERROR_ALREADY_EXISTS, the original code was violating good programming practices. This led to the implicit (undocumented) assumption that the user would not retry. The documentation did not tell the user about this assumption. And, when the assumption turned out to be wrong, _Singleton() behaved in a manner that was also contradictory to "ensuring that one and only one instance of the object". Incidentally, why was (and still is) _Singleton() creating the mutex with an initial lock? That is not appropriate if "the whole point" ... "is to ensure that one and only one instance of the object". The claim that _Singleton() can "ensure" anything at all is pretty bold given that _Singleton() is dynamically interpreted code with quite a few obvious possible points of failure. The most basic of these was that there is nothing sane that it can do if any DllCall() fails. Ultimately, _Singleton()'s promise to "Enforce a design paradigm where only one instance of the script may be running" is fundamentally impossible to keep as long as _Singleton() is a UDF. smartee's solution, now implemented, is a good workaround for what is a fundamentally broken idea. It's probably a better idea to get replace _Singleton() with a native code builtin-function. But as long as that is not an option, then smartee's solution is gold. My 2 cents on an old issue, but it needs to be pointed out that it was Valiks original _Singleton() that "was broken to begin with". Its smartee's source that is now in misc.au3, and he deserves credit for it.
- 6:56 PM Ticket #2356 (ControlGetText return blank string, but Window Info tool work without fail) updated by
- While testing beta 11 run into some regress: […] Help: Class names are linefeed (@LF) separated. - actually not. #2356 it seems its not work for me (for outpost window) […]
- 4:51 PM Ticket #2366 (For loop not working as expected) created by
- Here's some code I came across that isn't working as it should, at …
Jul 22, 2013:
- 7:34 PM Milestone 3.3.9.11 completed
- 2:38 PM Ticket #2355 (Custom compiler) updated by
- James don't tell me the only way is surrender... A custom compiler maybe is not the solution against hacker but at least after automatic tools, if the exe changes everytime you don't need a different approach everytime? Another way is maybe to obfuscate the Autoit Stub or make it "dynamic" every time it compile a new exe? ( we can't do it but some unofficial tools does it, i don't have try that tools because is breaks the AutoIt EULA ) or adding some random junkcode to some part of the code for deceive the automatic tools? I'm not an expert of this thing and probably i'm just saying crap words, but I can not believe at the phrase "I tried but there is nothing to do, sorry" for my part i'm trying to help in any way i can.
- 2:03 PM Ticket #2356 (ControlGetText return blank string, but Window Info tool work without fail) closed by
- Works For Me: ControlGetText() and Au3Info use the same engine in the next beta. If not resolved then reopen. But I will need an example script that I can use to repo.
- 1:25 PM Ticket #2365 (FileFindNextFile - information in @extended) created by
- At present FileFindNextFile sets @extended to 1 if the …
- 12:31 PM Ticket #2355 (Custom compiler) updated by
- AutoIt is a scripting language. When your script is compiled, the EXE is a result of the interpreter and source code being bundled together. Over the years Jon has always tried to defeat the hackers, but they get quicker and quicker each time.
- 11:48 AM Ticket #2362 (ControlGetText, WinGetTitle sometimes reads ANSI as Wide) closed by
- Fixed: Fixed by revision [8072] in version: 3.3.9.11
- 10:38 AM Ticket #2364 (Call with CallArgArray regression in beta) created by
- I found the following script does nt behave the same […]
- 9:41 AM Ticket #2363 (Call with invalid proc regression) created by
- The following script was working with standard release It does not …
- 9:38 AM Ticket #2213 (Problem with UDPOpen or UDPRecv an computer with more the one networc card) updated by
- Why you reject this bug? I need the correct working of this function in 2 of my projects!
- 9:01 AM Ticket #2361 (RegRead doesn't read REG_QWORD values) closed by
- Fixed: Fixed by revision [8068] in version: 3.3.9.11
- 8:24 AM Ticket #2362 (ControlGetText, WinGetTitle sometimes reads ANSI as Wide) created by
- Sometimes ControlGetText or WinGetTitle will return characters that …
- 8:00 AM Ticket #2361 (RegRead doesn't read REG_QWORD values) updated by
-
Version changed
Automatic ticket cleanup. - 7:49 AM Ticket #2361 (RegRead doesn't read REG_QWORD values) updated by
-
Type changed
- 7:48 AM Ticket #2361 (RegRead doesn't read REG_QWORD values) updated by
-
Owner, Status changed
Yeah that's weird. The part to read is completely missing. - 7:46 AM Ticket #2353 (FileSelectFolder doesn't refresh after creating new folder with ...) closed by
- No Bug: This looks to be a bug in the windows control rather than AutoIt.
- 7:43 AM Ticket #2311 (Wrong handling of casesense parameter in StringReplace) closed by
- Fixed: Fixed by revision [8067] in version: 3.3.9.11
- 2:00 AM Ticket #2361 (RegRead doesn't read REG_QWORD values) updated by
-
Version changed
Automatic ticket cleanup. - 1:31 AM Ticket #2361 (RegRead doesn't read REG_QWORD values) created by
- This is an inconsistency in how AutoIt works with Registry data. …
Jul 21, 2013:
- 11:32 PM Tickets #14,15,382,546,588,767,978,988,1034,1035,1120,1127,1186,1198,1373,1451,1497,1533,1547,1554,1645,1649,1681,1706,1709,1713,1723,1846,1869,1873,1919,1931,1943,2057,2109,2119,2122,2142,2164,2188,2220,2266,2278,2282,2321,2322 batch updated by
- Rejected
- 11:31 PM Tickets #1024,1231,1317,1336,1368,1472,1503,1650,1652,1667,1832,1870,1953,1954,2002,2018,2054,2058,2066,2091,2124,2152,2167,2168,2171,2181,2190,2210,2213,2279,2284,2299,2300,2309,2310,2312,2313,2315,2316,2317,2323 batch updated by
- Rejected
- 8:00 PM Ticket #2360 (implement optional byref parameter passing to function) updated by
-
Version changed
Automatic ticket cleanup. - 7:49 PM Ticket #2360 (implement optional byref parameter passing to function) created by
- Currently passing optional parameters is by value only... I will love …
- 6:48 PM Ticket #2311 (Wrong handling of casesense parameter in StringReplace) updated by
- This demonstrates the difference. […]
- 6:09 PM Milestone 3.3.9.10 completed
- 5:47 PM Ticket #2350 (Strange issue when using $SS_ETCHEDVERT and $SS_ETCHEDHORZ) closed by
- Fixed: Fixed by revision [8061] in version: 3.3.9.10
- 5:45 PM Ticket #2286 (GuiCtrtlGetState without a controlID parameter runs but aborts AutoIt) closed by
- Fixed: Fixed by revision [8060] in version: 3.3.9.10
- 2:44 PM Ticket #2358 (FileInstall: accept "" as "source" to include the current script) updated by
- The directive could be a solution as well ... probably better. In terms of improper usage, FileInstall is a very special function by its nature and I imagine it is always used "with a clear purpose". As the "source" has to be literal, there is no chance a non-initialized variable could offer a "fake" empty string. So, in my opinion, an "accidental" empty string shouldn't be a real concern.
Jul 20, 2013:
- 11:19 PM Ticket #2358 (FileInstall: accept "" as "source" to include the current script) updated by
- If this was to be accepted, I would say a pragma directive would be more appropriate. Imagine if a user mistakenly used "" in FileInstall and didn't mean to include their source.
- 10:00 PM Ticket #2358 (FileInstall: accept "" as "source" to include the current script) updated by
-
Version changed
Automatic ticket cleanup. - 9:53 PM Ticket #2358 (FileInstall: accept "" as "source" to include the current script) created by
- To the extent of my search, this issue wasn't raised before (sorry if …
- 11:51 AM Ticket #2274 (StringRegExp crashes on large string) closed by
- No Bug
- 11:49 AM Ticket #2274 (StringRegExp crashes on large string) updated by
- Use either patterns to avoid high backtracking: […] Both work fast with beta 3.3.9.8 on W7 X64/x86.
- 8:58 AM Milestone 3.3.9.9 completed
Jul 19, 2013:
- 10:14 PM Ticket #2351 (_ExcelBookSaveAs format XLSX (default workbook)) closed by
- Completed
- 10:14 PM Ticket #2351 (_ExcelBookSaveAs format XLSX (default workbook)) updated by
- This is currently in the beta v3.3.9.8.
- 9:59 PM Ticket #2320 (_IENavigate return values) closed by
- Fixed: Fixed by revision [8021] in version: 3.3.9.9
- 5:18 PM Ticket #1991 (Include CAPTUREBLT flag in _ScreenCapture_Capture) closed by
- Wont Fix
- 5:04 PM Ticket #1767 (_IETableWriteToArray does not handle Rowspan, ColSpan, and strips tags ...) closed by
- Rejected
Jul 18, 2013:
- 9:22 PM Ticket #1941 (Generate syntax files for Forum, Wiki) closed by
- Completed: Added by revision [8012] in version: 3.3.9.9
- 11:41 AM Milestone 3.3.9.8 completed
Jul 17, 2013:
- 12:00 PM Ticket #1942 (Better support for online documentation.) updated by
-
Milestone changed
Automatic ticket cleanup. - 11:49 AM Ticket #1942 (Better support for online documentation.) updated by
- HTML syntax has been tidied and updated to meet today's standards.
- 11:49 AM Ticket #1942 (Better support for online documentation.) closed by
- Fixed
Jul 16, 2013:
- 1:11 PM Ticket #2355 (Custom compiler) updated by
- I'd like to know what devs think about this Feature Request. Seems an important step for security development and i'm agree in every step in that direction
- 10:52 AM Ticket #2340 (_GUICtrlListView_SimpleSort changes sort parameter variable value) closed by
- Completed: Added by revision [7935] in version: 3.3.9.8
- 9:13 AM Ticket #2338 (Here is a Modification to _ArraySearch UDF) closed by
- Completed: Added by revision [7931] in version: 3.3.9.8
- 8:25 AM Ticket #2357 ($WM_SIZING missing in WindowsConstants.au3 in 3.3.9.7) updated by
- I added back Global Const $WM_SIZING = 0x0214 to WindowsConstants.au3.
- 8:23 AM Ticket #2357 ($WM_SIZING missing in WindowsConstants.au3 in 3.3.9.7) closed by
- Completed: Added by revision [7928] in version: 3.3.9.8
Jul 15, 2013:
- 10:30 PM Ticket #2352 (_ExcelWriteSheetFromArray incorrect start row and col array) updated by
- I understand, but you can just change the parameters. I agree the Defaults should be 0, but it's not worth a script breaking change.
- 10:21 PM Ticket #2357 ($WM_SIZING missing in WindowsConstants.au3 in 3.3.9.7) updated by
- This is a valid issue that will be fixed.
- 12:26 PM Ticket #2357 ($WM_SIZING missing in WindowsConstants.au3 in 3.3.9.7) created by
- Hello, if I want to compile my script with the latest beta-version …
- 6:42 AM Ticket #2352 (_ExcelWriteSheetFromArray incorrect start row and col array) updated by
- Replying to BrewManNH: > That is the function's default setting, it has nothing to do with the array starting at 0 or not. The function appears to have been written to assume the array count is kept in $array[0][0] and the data in the array starts as 1. Unfortunately, the data in the Excel workbook recorded starting from a position [0][0] in this function. In order to properly record the whole array of information, you need to specify all the parameters for the function with the start [0][0] or the easiest way to fix the function itself ... Sorry for my bad English.
Note:
See TracTimeline
for information about the timeline view.
