Context Navigation

← Previous Period
Next Period →

Timeline

Jul 24, 2008:

4:16 PM Ticket #460 (Better error display during Aut2Exe) created by Valik: Display UPX errors. Display error if adding a custom icon fails.
8:50 AM Milestone 3.2.13.5 completed
6:57 AM Ticket #452 (virus found in v3.2.12.1 released (12th June, 2008)) updated by Valik: Saunders, you may be on to something there. At least for Trac. But it boils down to, "Does Valik want to play with Python again and does Valik have time to get anything done". I'm pretty sure something could be put together with the Trac API. I've already done some stuff with Subversion post-commit hooks to do Trac related things via the various APIs. It makes me wonder if there's a Trac-side pre-ticket-create event that could be tapped into to re-direct people to certain pages based on data detected in the summary/title.
5:25 AM Ticket #452 (virus found in v3.2.12.1 released (12th June, 2008)) updated by Rob Saunders <rob@…>: Someone needs to hack the bug tracker (and forums ideally) so that if it detects the word "virus" in a post it suggests they read our virus information thread before they are actually post their bug. :P (Not a serious suggestion, but wouldn't it be nice?)

Jul 22, 2008:

4:03 PM Ticket #459 (need run under pure dos) closed by Valik: Rejected: I'm at a loss for a way to express how colossally stupid this request is so I'm simply going to close it.
4:00 PM Ticket #459 (need run under pure dos) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
3:53 PM Ticket #458 (($var == '')=true for, Array, DllStruct.(?)) closed by Valik: No Bug: Given that you used the STRING COMPARE OPERATOR, what part about this is a bug? Anyway, this isn't a bug no matter what operator you use. Internally, types are changed around during comparisons and types that don't have a string representation return an empty string. Not a bug.
3:46 PM Ticket #459 (need run under pure dos) created by anonymous: Wonder if can also produce such a out.exe that can run under pure dos …
1:33 PM Ticket #458 (($var == '')=true for, Array, DllStruct.(?)) updated by mvgulik: return behavior switches from false to true between v3.0.102.0 and v3.1.0.15
12:36 PM Ticket #458 (($var == '')=true for, Array, DllStruct.(?)) updated by mvgulik: ignore the v3.2.12.1(missing in version list) part.
12:23 PM Ticket #458 (($var == '')=true for, Array, DllStruct.(?)) created by mvgulik: ($var == ) = true for, Array, DllStruct.(?) not sure if this is …
10:49 AM Ticket #440 (EOF character at end of script causes parse error.) closed by J-Paul Mesnage: Fixed: Fixed in version: 3.2.13.5
3:37 AM Ticket #457 (I'm a moron and like to swear in ticket titles.) closed by Valik: No Bug: Replying to anonymous: > Replying to Valik: > > Ticket title changed. Seriously, was that necessary? > So and your comment and title is/was also necessary? I don't really think that's relevant. You created a ticket for something that isn't a bug. Can you demonstrate the code, as written, presents a problem?. To top it off you do so by creating a ticket with a profane title. Why shouldn't I go out of my way to discourage you from ever ~~wasting my time~~ using the issue tracker again? You're not off to an auspicious start here. And your behavior has earned you a vacation from the forum. The lesson(s) you need to take from this is/are 1) Think before you act; 2) If you're going to be an ass-hat, wear it somewhere else, please. I'm closing this. Quite obviously, and as Gary pointed out, this is not a bug. The next array element ($i + 1) is read in the loop which means the loop must stop at UBound() - 2 which is what the code reflects. Otherwise the code will attempt to index out of bounds.
2:00 AM Ticket #456 (simple drawing commands) updated by TicketCleanup: Version, Milestone changed
Automatic ticket cleanup.
1:45 AM Ticket #455 (Request new feature guictrlgetbkcolor) closed by Gary: Duplicate: Duplicate of #119
1:29 AM Ticket #457 (I'm a moron and like to swear in ticket titles.) updated by Gary: I believe the loop is correct, if it is a 1 dimension array then you move everything up the array by one, being it is moving everything by one it needs to stop 2 before the end of the array. Same goes for a 2 dimension array.
1:23 AM Ticket #457 (I'm a moron and like to swear in ticket titles.) updated by Gary: Owner, Status, Component changed
1:19 AM Ticket #457 (I'm a moron and like to swear in ticket titles.) updated by anonymous: Replying to Valik: > Ticket title changed. Seriously, was that necessary? So and your comment and title is/was also necessary?
12:35 AM Ticket #457 (I'm a moron and like to swear in ticket titles.) updated by Valik: Summary changed
Ticket title changed. Seriously, was that necessary?
12:30 AM Ticket #457 (I'm a moron and like to swear in ticket titles.) created by Pascal258: Inside of _ArrayDelete you get "Local $iUBound = UBound($avArray, 1) - …
12:19 AM Ticket #456 (simple drawing commands) closed by Valik: Rejected: Graphic controls, I suggest you look it up in the documentation. Rejected, mostly because it's already implemented... and has been for years.
12:11 AM Ticket #456 (simple drawing commands) created by richardbrew@…: Hi: I would like to see simple drawing commands i.e. circle, square, …
12:00 AM Tickets #438,455 batch updated by TicketCleanup: Version changed
Automatic ticket cleanup.

Jul 21, 2008:

10:23 PM Ticket #455 (Request new feature guictrlgetbkcolor) created by Jmosley708@…: I would like to read the color of the control. Guictrlsetbkcolor lets …
10:00 PM Ticket #438 (Vista 64: ProgramDir) closed by J-Paul Mesnage: Fixed: Replying to Valik: > > Funny thing: When pressing F5, Scite launches the X86 Version from AutoIt (at least, I think so), because @programdir resolves to the x86 version. > > If the .au3 script is started from the explorer, the x64 version is used and fails to find the program the script should launches. > I did complete test under Vista64 and everything works as expected. The reason why is Scite only launch the X86 version is because Scite is a 32-bit process
9:54 PM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) closed by J-Paul Mesnage: Duplicate
9:45 PM Ticket #449 (Problems with XP x64 redirection) closed by J-Paul Mesnage: Fixed: Fixed in version: 3.2.13.5
4:19 PM Ticket #454 (FileRead handle files as UTF-8 even BOM is missing) updated by Valik: Summary changed
It's not necessary to put a tag describing the type of ticket in the title given there's a field for inputting that information…
4:17 PM Ticket #453 (ControlSend dont work properly) closed by Valik: No Bug: We only claim support for standard Microsoft controls. You're trying to send to a game or something. If it works, great, if not, well, sucks to be you. And in this case, it sucks to be you because this is certainly not a bug.
2:33 PM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) updated by J-Paul Mesnage: the problem has been solved in 3.2.13.0 see ticket #339
2:00 PM Ticket #454 (FileRead handle files as UTF-8 even BOM is missing) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
1:45 PM Ticket #454 (FileRead handle files as UTF-8 even BOM is missing) created by Nitrogen: I have many UTF-8 file without BOM. When I tried to open files using …
4:06 AM Ticket #453 (ControlSend dont work properly) created by h3ir: Full Thread: …

Jul 20, 2008:

10:41 PM Ticket #451 (GUICtrlCreateCombo don't show items on Windows 2000) updated by Tlem: All done. I'm really confused to have created a ticket for that. I'll try this script on XP and Vista before and it was working ! I never imagine that on Win2000 it was so simple. So one more time, excuse me. :(
8:17 PM Ticket #452 (virus found in v3.2.12.1 released (12th June, 2008)) closed by Valik: No Bug: I'm tired of these already. People really need to search first.
6:17 PM Ticket #447 (Display AutoIT Version infromation in About Screen) closed by Jos: Rejected
6:16 PM Ticket #452 (virus found in v3.2.12.1 released (12th June, 2008)) updated by Jos: Have you searched our forums before posting a bug here? There is a sticky about this subject in the support forum: Are my AutoIt EXEs really infected? http://www.autoitscript.com/forum/index.php?showtopic=34658 Jos
6:00 PM Ticket #452 (virus found in v3.2.12.1 released (12th June, 2008)) updated by TicketCleanup: Severity changed
Automatic ticket cleanup.
5:07 PM Ticket #452 (virus found in v3.2.12.1 released (12th June, 2008)) created by allison@…: it apears there is a virus or a virus signature found in autoitsc.bin …
10:33 AM Ticket #451 (GUICtrlCreateCombo don't show items on Windows 2000) closed by J-Paul Mesnage: No Bug: see doc GuiCtrlCreateCombo
2:00 AM Ticket #451 (GUICtrlCreateCombo don't show items on Windows 2000) updated by TicketCleanup: Severity changed
Automatic ticket cleanup.
1:03 AM Ticket #451 (GUICtrlCreateCombo don't show items on Windows 2000) updated by Jos: Pretty sure this has always been like this and you have to change this line to: $Combo1 = GUICtrlCreateCombo("", 16, 16, 145, 80) Jos
12:57 AM Ticket #451 (GUICtrlCreateCombo don't show items on Windows 2000) created by Tlem: This simple code don't work on Windows 2000. The only think I can see, …

Jul 19, 2008:

4:00 PM Ticket #346 (Remove the FileOpenDialog/FileSaveDialog filter length limit) updated by TicketCleanup: Milestone changed
Automatic ticket cleanup.
4:00 PM Ticket #346 (Remove the FileOpenDialog/FileSaveDialog filter length limit) closed by J-Paul Mesnage: Fixed
1:28 PM Ticket #450 (SciTE4AutoIT - Export to PDF) closed by Jos: Wont Fix: We do not maintain the core code of SciTE but use the version as published by Neil Hodgson. If there is anything wrong with SciTE you need to go to the SciTE interest website.
1:27 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by Jos: Again Both programs have NO relation to the release version of autoit. For SciTE4AutoIt3 the only file that is related to the version of AutoIt3 is au3.keywords.properties. Also when you run or compile scripts in SciTE4AutoIt3 the version of all used programs is shown in the OutputPane. Jos
1:23 PM Milestone 3.2.13.4 completed
12:06 PM Ticket #387 (Change DllCallbackFree() to check handle validation or erase it) closed by Jon: Fixed: Fixed in version: 3.2.13.4
11:26 AM Ticket #387 (Change DllCallbackFree() to check handle validation or erase it) updated by Jon: Oh I see. K, I've removed the message for this and DllClose() as well.
10:00 AM Ticket #450 (SciTE4AutoIT - Export to PDF) updated by TicketCleanup: Milestone changed
Automatic ticket cleanup.
8:30 AM trymenu.pdf attached to Ticket #450 by muthukumars@…: Sample PDF File
8:29 AM Ticket #450 (SciTE4AutoIT - Export to PDF) created by muthukumars@…: Word wrap not enable during PDF Export.
7:57 AM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by muthukumars@…: Replying to Jos: > "Fine. SciTE4AutoIt3 able to call autoIt to Compile au3 file ?" > Yes ... and the your point is what ? > My requirement is SciTE4AutoIt3 able to display autoIt version in about screen or some ware else. To Understand User/programmer while using SciTE4AutoIt3 GUI > "aut2exe version is nothing but release number ?" > Have no idea what you are asking here but I said that the actual aut2exe program in not directly related the to autoit3 version. > > Just version number to track change
7:52 AM Ticket #277 (@ProcessorArch) updated by J-Paul Mesnage: Replying to anonymous: > Replying to Jon: > > http://www.osdev.org/wiki/X86-64 > bad link !!! link now works
2:51 AM Ticket #449 (Problems with XP x64 redirection) created by BikinDutchman: x86 Scripts and compiled executables expand program and system dirs as …

Jul 18, 2008:

9:12 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by Jos: "Fine. SciTE4AutoIt3 able to call autoIt to Compile au3 file ?" Yes ... and the your point is what ? "aut2exe version is nothing but release number ?" Have no idea what you are asking here but I said that the actual aut2exe program in not directly related the to autoit3 version.
5:25 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by anonymous: correct me if i am wrong.. sorry spelled wrong
5:21 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by anonymous: Replying to Jos: > by the way, the same counts for au3info and aut2exe programs. > au3info is just a program to show information about windows/controls. > aut2exe is a programs that translates your script and wraps it with the appropriate AutoItSC*.bin file which is updated with each release. As per understand au3info separate application. if any change made in au3info it should identify with number only ? aut2exe version is nothing but release number ? correct to i am wrong..
5:15 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by anonymous: Replying to Jos: > SciTE4AutoIt3 executable doesn't have any relation ot an Autoit3 release, only the au3.keywords.properties file which does contain the AutIt3 version information. Fine. SciTE4AutoIt3 able to call autoIt to Compile au3 file ?
5:10 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by Jos: by the way, the same counts for au3info and aut2exe programs. au3info is just a program to show information about windows/controls. aut2exe is a programs that translates your script and wraps it with the appropriate AutoItSC*.bin file which is updated with each release.
4:47 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by Jos: SciTE4AutoIt3 executable doesn't have any relation ot an Autoit3 release, only the au3.keywords.properties file which does contain the AutIt3 version information.
4:37 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by anonymous: Replying to Valik: > What About dialog? Aut2Exe? Au3Info? Au3info, aut2exe as well as SciTE4AutoIt. Even you can add Beta version information in SciTE4AutoIt.
2:16 PM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) updated by J-Paul Mesnage: for the time being as my notebook is broken I have no access to Vista Sp1. I cannot reproduce it with XP Sp2. As soon I have my notebook repaired I will analyse the problem.
9:25 AM Ticket #446 (OnAutoIt and SciTE) updated by JamesBrooks: Thanks guys! No problem, I just noticed they werent found when I was having to call outputs when the script finished.
6:31 AM Ticket #448 (Make AutoIt harder to extract embedded script) closed by Valik: Rejected: Replying to OptimusB@optonline.net: > Bascially, the whole point why I used AutoIt3 in the first place has been defeated by this MyAutToExe program. Then you were using AutoIt for the wrong reason from the beginning. > If you need more information, let me know. Why would we need more information on a subject that has been discussed to death? Or did you not bother actually researching the issue first. Closing as rejected. That's not to say we don't know or care about the issue. But we do not need an open ticket on it so everybody can come along and chime in with their many worthless opinions.
6:00 AM Ticket #448 (Make AutoIt harder to extract embedded script) updated by TicketCleanup: Version, Milestone changed
Automatic ticket cleanup.
5:11 AM Ticket #448 (Make AutoIt harder to extract embedded script) created by OptimusB@…: I have tried and tested MyAutToExe and it not extracts the AutoIt3 …

Jul 17, 2008:

9:11 PM Ticket #446 (OnAutoIt and SciTE) closed by Valik: No Bug: These are user-defined event callback functions. They aren't any different than any other event callback except that AutoIt implicitly calls it instead of requiring explicit registration (a design flaw). Going ahead and closing as no bug. I don't want Jos to make any special considerations for these two unique functions (not that I think he would) because any special provisions may interfere with some unreleased code I have that none of you know about.
9:07 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by Valik: What About dialog? Aut2Exe? Au3Info?
8:49 PM Ticket #446 (OnAutoIt and SciTE) updated by Jos: James, How do you envision this to be a bug and what would you expect SciTE to do with these Func names? Jos
8:00 PM Ticket #447 (Display AutoIT Version infromation in About Screen) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
7:04 PM Ticket #447 (Display AutoIT Version infromation in About Screen) created by anonymous: Display Auto IT Version information in About Screen.
6:51 PM Ticket #446 (OnAutoIt and SciTE) created by JamesBrooks: Currently, SciTE does not recognise the OnAutoIt* functions as correct …

Jul 16, 2008:

8:00 AM Ticket #445 (SubStructure Support in Structure Tags) updated by TicketCleanup: Milestone changed
Automatic ticket cleanup.
7:48 AM Ticket #444 (Clone Structures with Data and Tags) closed by Valik: Rejected: If you need to copy one structure to another, you can do it easily enough by allocating a new destination structure and using DllCall() with memcpy or CopyMemory.
7:44 AM Ticket #445 (SubStructure Support in Structure Tags) closed by Valik: Rejected: There's no need to clutter the syntax further, it's hard enough as is. "Nested" structures can be done inline anyway so this doesn't really do much beyond make the syntax that much more obscure. Rejected.
7:43 AM Ticket #443 (Return Tag String for Structure) closed by Valik: Rejected: Other than maybe diagnostic purposes, there isn't a use for such functionality. You're trying to solve a theoretical problem with the wrong solution. Closing as rejected.
6:38 AM Ticket #445 (SubStructure Support in Structure Tags) created by amel27: If possible, about this sample: […]
6:20 AM Ticket #444 (Clone Structures with Data and Tags) created by amel27: Existent assignment operators clone Pointers of Structures instead of …
4:21 AM Ticket #443 (Return Tag String for Structure) created by amel27: If possible, about DLLStructGetTag($tStruct) - for verifying …

Jul 15, 2008:

6:27 PM Ticket #439 (ping function doesnt work for vista) closed by Jos: No Bug
6:00 PM Tickets #441,442 batch updated by TicketCleanup: Version changed
Automatic ticket cleanup.
5:58 PM Ticket #441 (Proposed changes to _StringAddThousandsSep()) closed by Valik: Duplicate: Closing as duplicate of #442.
5:41 PM Ticket #442 (Proposed changes to _StringAddThousandsSep()) created by GEOSoft: This allows for regional settings. […]
5:39 PM Ticket #441 (Proposed changes to _StringAddThousandsSep()) created by anonymous: This allows for regional settings. […]
12:13 AM Ticket #440 (EOF character at end of script causes parse error.) created by ptheckler@…: Some editor programs add an EOF character (hex 1A) to the end of a …

Jul 14, 2008:

6:26 PM Ticket #439 (ping function doesnt work for vista) updated by Jos: See my answer in the thread, but you didn't specify a valid hostname or IP addres. The parameter cannot contain a URL. Jos
2:37 AM Ticket #439 (ping function doesnt work for vista) created by yoop: function ping() does not work on Windows Vista 32 and 64 Bit Version, …

Jul 13, 2008:

10:49 PM Ticket #437 (InetGet in background mode - loop not responding when site overloaded) closed by Valik: Wont Fix: I'm closing this as "Won't Fix". There isn't a way to fix this which will work correctly in all cases. The current method is the least weird of all the various possible outcomes.
10:45 PM Ticket #436 (Aut2Exe more efficient from command line?) closed by Valik: Fixed: Fixed in version: 3.2.13.4
10:25 PM Ticket #438 (Vista 64: ProgramDir) updated by Valik: Replying to Marc: > Hi, > > under Vista64 we find two Program Files-Folders: > 1. Program Files > 2. Program Files (x86) > > The help file suggests > {{{ > @SystemDrive & "\Program Files(x86)" > }}} > But: The Macro @SystemDrive does not exist and there is a space missing before the "(x86). You do not state where this is in the documentation but I found it none-the-less. I've fixed what you mention and a couple other issues. It no longer contains the mis-leading non-existent macro. > Funny thing: When pressing F5, Scite launches the X86 Version from AutoIt (at least, I think so), because @programdir resolves to the x86 version. > If the .au3 script is started from the explorer, the x64 version is used and fails to find the program the script should launches. Hmm, is your Explorer the 64-bit version? If so, it's probably looking in "Program Files" which is where 64-bit binaries go. Since AutoIt installs the 64-bit binaries along-side the 32-bit binaries via a 32-bit installer everything goes into the "Program Files (x86)" folder. This sounds like a problem with how our installer sets things up, however.
9:53 PM Ticket #427 (add latest SciTE info to ...) updated by anonymous: Hi Jos. Is the download URL for the SciTE Editor [1] static? I honestly don't know. If not, what do you think about adding the download URL to that http://www.autoitscript.com/autoit3/scite/download/scite4autoit3version.ini ? Regards, Rudi. [1] currently the download URL is pointing to "http://www.autoitscript.com/cgi-bin/getfile.pl?../autoit3/scite/download/SciTE4AutoIt3.exe"

Jul 12, 2008:

10:03 PM Ticket #438 (Vista 64: ProgramDir) created by Marc: Hi, under Vista64 we find two Program Files-Folders: 1. Program …

Jul 10, 2008:

9:10 PM Ticket #437 (InetGet in background mode - loop not responding when site overloaded) updated by Zedna: Sorry - now as I think more about that maybe InetGet('abort') may be "blocking" as you said. But I'm not sure.
9:06 PM Ticket #437 (InetGet in background mode - loop not responding when site overloaded) updated by Zedna: Replying to Zedna: > It looks like evaluating of @InetGetActive macro blocks program flow. Or evaluating of @InetGetBytesRead macro may block program flow.
9:04 PM Ticket #437 (InetGet in background mode - loop not responding when site overloaded) updated by Zedna: Replying to Valik: > Before I close this, I'll just ask this. Can you confirm the code is blocking at InetGet("abort")? I didn't run or test your code, I just looked at AutoIt's internals to see where it could be blocking at and InetGet("abort") is all I see. I want to make sure that's what it really is before I close this. I can't confirm this because when WWW site is busy/overloaded it looks like program flow is not inside While @InetGetActive loop. It looks like evaluating of @InetGetActive macro blocks program flow. With InetGet('abort') there is no problem when WWW site is responding correctly. In this case when I manually stop download by Esc then download stops OK. But when WWW site is busy/overloaded program never/very late reaches code/conditions inside my While @InetGetActive loop. There is code for displaying progress (percentage) of download when it takes more than two seconds but this code is never/very late executed in this case. So I don't think this problem can be in relation with InetGet('abort').
5:35 PM Ticket #437 (InetGet in background mode - loop not responding when site overloaded) updated by Valik: I don't think there's much that can be done about this. When a download is stopped, it can block for a little bit. The API doesn't always honor the cancel request immediately. AutoIt internally blocks until the background thread is complete because otherwise it would report True for @InetGetActive checked immediately after InetGet("abort"). Basically, there's blocking code in place to prevent an obvious race condition. The flip side of that is short-circuiting the blocking code and making sure @InetGetActive returns false when it should. The problem there becomes it would be possible to start a second download before the first one was canceled. This would lead to a hard crash since a shared data structure is used since we only allow one download. In short, my best guess looking at AutoIt's implementation and your code is that everything is working correctly. All the synchronization code must be there to prevent crashing or AutoIt lying about it's state. Before I close this, I'll just ask this. Can you confirm the code is blocking at InetGet("abort")? I didn't run or test your code, I just looked at AutoIt's internals to see where it could be blocking at and InetGet("abort") is all I see. I want to make sure that's what it really is before I close this.
4:58 PM Ticket #437 (InetGet in background mode - loop not responding when site overloaded) created by Zedna: InetGet in background mode - loop not responding I have created small …
3:59 PM Ticket #436 (Aut2Exe more efficient from command line?) created by rob@…: When I used the Aut2Exe GUI to compress a script it came out to 311kb, …
2:36 PM Ticket #434 (small mistake in documentation for _IECreate function) updated by DaleHohm: Noted. Doc update will be submitted. A value of 0 prevents the window from explicitly taking focus. Dale Replying to olexiyb@gmail.com: > Mistake in doc of _IECreate. > sorry because of smap blocker I was not able to copy documentation part. It just keep rejecting it. > > See parameter f_takeFocus documentation, both options have the same descriptions. I think 0 does something different. > > Olexiy
10:34 AM Ticket #435 (MyProg.exe (Not Responding)) closed by Gary: Rejected: This is not the support forum. For support of your scripts start a thread on the forum.
8:49 AM Ticket #435 (MyProg.exe (Not Responding)) updated by anonymous: please email me at jacobeamor at live dot ca
8:47 AM Ticket #435 (MyProg.exe (Not Responding)) updated by anonymous: I made a simple browser script where i can access the internet but when I went to runescape.com and tried to play my program kept freezing saying its not responding... I was wondering if anyone has any idea how to fix this problem. if you wouldnt mind emailing me back with your thoughts it would be most apreciated. jacobeamor@…
8:47 AM Ticket #435 (MyProg.exe (Not Responding)) created by jacobeamor@…: I made a simple browser script where i can access the internet but …

Jul 8, 2008:

6:40 PM Ticket #423 (samples) closed by Jos: Rejected
6:31 PM Ticket #427 (add latest SciTE info to ...) closed by Jos: Rejected: closing
4:00 PM Ticket #434 (small mistake in documentation for _IECreate function) updated by TicketCleanup: Milestone changed
Automatic ticket cleanup.
2:47 PM Ticket #434 (small mistake in documentation for _IECreate function) created by olexiyb@…: Mistake in doc of _IECreate. sorry because of smap blocker I was not …

Jul 7, 2008:

4:06 PM Ticket #433 (Au3Check unexpected behaviour) closed by Valik: No Bug: This is not a bug. You should only look at the top error, fix it, re-check and move on. Things like syntax errors can throw off the check because they are syntax errors which means the script is malformed.
12:35 PM Ticket #433 (Au3Check unexpected behaviour) created by TomZ (tom.vd.zanden /at\ gmail D0T c[]m): […] […] Due to the unbalanced brackets in bogus_function, …
5:49 AM Ticket #424 (_Dec64()) updated by Ultima: I'm not sure how much trouble it would be, but I think (if at all possible) AutoIt's built-in integer functions need to have added support for handling a entire int64 variant. I also ran into the "only 32-bit integers supported" issue recently, and had to come up with some funky recently, and had to come up with some funky workaround (which I suspect might fail depending on architecture, though I can't be too sure). I stopped by this bugtracker to request for the change (to have the bitwise operators be int64-aware), but found this ticket... which sounds similar enough that it would probably do better to keep the entire request in a single ticket. Ticket summary change? "Support int64 in more/all integer-related functions (where it makes sense)" (or something to that effect).
4:12 AM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) updated by koshyjohnuk: Is any other developer with Vista going to look at this? Or is there any other information that I can provide which will help with diagnosis?

Jul 6, 2008:

5:23 PM Ticket #432 (new version au3 always UPX compresses) updated by Valik: Or, heaven forbid, actually run the compiler manually and configure the options. You do realize there is a compiler GUI, right?
1:08 PM Ticket #432 (new version au3 always UPX compresses) closed by Gary: No Bug: Place #AutoIt3Wrapper_UseUpx=n at the top of your script
9:25 AM Ticket #432 (new version au3 always UPX compresses) created by vr@…: The previous version of AutoIT permitted people to optionally UPX …
9:06 AM Ticket #431 (General help and support forum request.) updated by anonymous: Replying to Valik: > Replying to MerkurAlex: > > I am requesting that there be a solved button added for the poster so that he may click it and it would add "[Solved]" to the beginning of the topic name automatically this would be nice to have but if no one has the time that's fine. > > Not going to happen. First, I know most people on this forum are one-post wonders and won't use it anyway. Second, it would require effort to get it working which none of us wish to put into it. > > > Also i think people should be able to delete they're posts this would remove the need for the solved button and if people use it then we would have a cleaner forum. > > No, that's counter-intuitive. The forum would be a cleaner place if people would search it before asking their question that's already been answered thirty-two times. Deleting information is not the way to keep the forum clean, keeping people from creating redundant threads would keep it clean. But that's impossible to do. I just thought about the delete button and yes that wouldn't make sense and i understand that you guys don't have the time for the solved button so thanks for reading and good luck with everything!
4:00 AM Ticket #431 (General help and support forum request.) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
3:34 AM Ticket #431 (General help and support forum request.) closed by Valik: Rejected: Replying to MerkurAlex: > I am requesting that there be a solved button added for the poster so that he may click it and it would add "[Solved]" to the beginning of the topic name automatically this would be nice to have but if no one has the time that's fine. Not going to happen. First, I know most people on this forum are one-post wonders and won't use it anyway. Second, it would require effort to get it working which none of us wish to put into it. > Also i think people should be able to delete they're posts this would remove the need for the solved button and if people use it then we would have a cleaner forum. No, that's counter-intuitive. The forum would be a cleaner place if people would search it before asking their question that's already been answered thirty-two times. Deleting information is not the way to keep the forum clean, keeping people from creating redundant threads would keep it clean. But that's impossible to do.
2:28 AM Ticket #431 (General help and support forum request.) created by MerkurAlex: I am requesting that there be a solved button added for the poster so …

Jul 4, 2008:

5:41 PM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) updated by Gary: hmmm, don't have sp1 to test, I'm on WinXP Pro SP3
4:50 PM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) updated by koshyjohnuk: Installed 3.2.12.1 The crash still occurs: Problem signature: Problem Event Name: APPCRASH Application Name: AutoIt3.exe Application Version: 3.2.12.1 Application Timestamp: 4850e379 Fault Module Name: AutoIt3.exe Fault Module Version: 3.2.12.1 Fault Module Timestamp: 4850e379 Exception Code: c0000005 Exception Offset: 0003c4b4 OS Version: 6.0.6001.2.1.0.768.3 Locale ID: 1033 Additional Information 1: fd00 Additional Information 2: ea6f5fe8924aaa756324d57f87834160 Additional Information 3: fd00 Additional Information 4: ea6f5fe8924aaa756324d57f87834160 I'm running Windows Vista SP1 (Home Premium). I installed 3.2.12.1 and restarted the system just to be doubly sure. Ran the code and as before, it just crashed immediately after pressing 'Yes'. The crash does NOT occur if I comment out the 'GuiCtrlSetState(-1,$GUI_DISABLE)' line. It happened in a much bigger program and I distilled it down to the above code. The crash occurs EVEN if I re-enable the control using 'GuiCtrlSetState($i_img,$GUI_ENABLE)' and then try to delete it. The exception code and offset in the error details given by windows remain the same.
2:00 PM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) updated by Gary: Doesn't crash for me in 3.2.12.1 release or 3.2.13.3 beta
10:00 AM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) updated by TicketCleanup: Severity changed
Automatic ticket cleanup.
8:51 AM Ticket #430 (Deleting disabled image controls hard crashes AutoIt) created by koshyjohnuk@…: The summary and the following code should be enough to understand the …

Jul 3, 2008:

8:23 PM Ticket #429 (shellexecute() new feature) closed by Valik: Rejected: Replying to lookinmyeyes: > I have code that i would use runasset() to change the profile that a program will run under with version 3.10, > i used shellexecute() after runasset() to elevate the shellexecute to specifig user privileges. You must have a magical version of AutoIt, then. What you suggest just simply was not implemented that way. You were still running the script in the context of the caller, not the callee you thought. In other words, removing RunAsSet() did not remove any functionality some of you think you had. > i know i can use > ShellExecute("rundll32.exe", "shell32.dll, OpenAs_RunDLL " & $filename, "", "runas") > > to get the windows run as box, but this requires to enter username and password after they have been entered into the autoit code to start up the application. > > I am suggesting something like shellexecuteas() or something similar to runas() so that we can specify in the code username and password to use. > This is not going to happen. The API does not support it. What you can do, however, is use the /AutoIt3ExecuteLine feature of AutoIt. You can leverage that along with RunAs() to invoke ShellExecute() from an instance of AutoIt running as the user you want. The code would be something like: […] You will have some trouble with quotes, it's finicky getting them right since you must pass valid AutoIt syntax to /AutoIt3ExecuteLine and you must pass it as a SINGLE parameter (meaning the item has to be quoted itself). But basically you copy the AutoIt interpreter (A compiled script is fine) to a location UserB can access. Then you run that interpreter and have it execute your ShellExecute() line under the context of UserB. Then you clean up.
8:00 PM Ticket #429 (shellexecute() new feature) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
7:11 PM Ticket #429 (shellexecute() new feature) created by lookinmyeyes: I have code that i would use runasset() to change the profile that a …
6:35 PM Ticket #423 (samples) updated by Jos: You mean like the already included Snippet holder written by Gary?
6:31 PM Ticket #427 (add latest SciTE info to ...) updated by Jos: The AutoIt3 installer and SciTE4AutoIt3 installer are maintained separately and the SciTE4Autoit3 has its own version file already available: http://www.autoitscript.com/autoit3/scite/download/scite4autoit3version.ini I have build a check in SciTEConfig that downloads this file to verify whether an update is available. Jos
5:13 PM Ticket #428 (avast antivirus blocking autoit as a virus) closed by Valik: No Bug: http://www.autoitscript.com/forum/index.php?showtopic=34658
5:06 PM Ticket #428 (avast antivirus blocking autoit as a virus) created by fred.dixon@…: the july-03-08 virus sigs update is now blocking autoit scripts from …
4:00 PM Ticket #427 (add latest SciTE info to ...) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
3:28 PM Ticket #427 (add latest SciTE info to ...) created by rthilo: Hello Developers Team. What do you think about adding a section …
2:00 PM Ticket #426 (Compability with cryptors & packers) updated by TicketCleanup: Version, Milestone changed
Automatic ticket cleanup.
12:15 PM Ticket #426 (Compability with cryptors & packers) created by anonymous: AutoIt is incompatible with WinLicence v2.0 and themida 2.0+ Autoit is …

Jul 2, 2008:

10:00 PM Ticket #425 (Change to the registy by the installer) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
9:52 PM Ticket #420 (Scope bug or mis-wording in documentation) updated by evilertoaster: I'm not sure one way or the other if you have or to what extent you've talked about it internally, I didn't see anything suggestive when I searched about it initially... I can definitely understand not wanting to create a headache of more script breakers this late in development though. I'd think it more important convention-wise than the ones done last May, but I guess if you've weighed it against the trouble it would cause for old scripts then it could also be more significant. The example script was a much simplified case; the original discovery was from a local->'block local' instead of a global->local. The no-entry point is probably not ideal, but I think it's somewhat common in scripting languages...I'd tend to disagree about it being 'far worse'. Anyways- if it has already been discussed at length then there's no use me continuing other than to be a voice for the side of changing it and to have some archived note of it somewhere. It's fair to say you know what you're doing at this point :) Thanks for your time-
9:13 PM Ticket #425 (Change to the registy by the installer) closed by Valik: Rejected: George, see "HKEY_LOCAL_MACHINE\SOFTWARE\AutoIt v3\AutoIt". Specifically the "InstallDir" and "betaInstallDir" values. Closing as rejected.
8:01 PM Ticket #425 (Change to the registy by the installer) created by GEOSoft: The standard method of finding the path to the AutoIt3 folder is to …
8:00 PM Ticket #424 (_Dec64()) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
6:03 PM Ticket #424 (_Dec64()) created by Albuquerque: I had a bit of frustration when trying to convert an IPv4 address to …
2:07 AM Ticket #420 (Scope bug or mis-wording in documentation) updated by Valik: What makes you think we haven't talked about it? Besides, it's a little late in the game to go and change things now. Many scripts would be broken if scope suddenly got more granular. I can't say that all the code that would be broken is good code, but never-the-less, much code would be broken for very little reason. Most people don't even realize AutoIt *isn't* block-scoped so this isn't as critical an issue as you're making it out to be. By the way, the very reason you found the "bug" in the first place is because you're using what I'd consider a far worse "feature" of AutoIt. That being we don't enforce an entry-point function which means you are free to write any code at global scope. If you're so concerned about scope issues, then I would think you'd come up with your own personal convention like I have where you never have code at global scope unless it's part of a variable definition.
2:00 AM Ticket #423 (samples) updated by TicketCleanup: Version, Milestone changed
Automatic ticket cleanup.
1:59 AM vbs.jpg attached to Ticket #423 by anonymous
1:59 AM Ticket #423 (samples) created by iceberg: hi wondering if it is possible to include the SAMPLE features inside …
12:16 AM Ticket #420 (Scope bug or mis-wording in documentation) updated by evilertoaster: My comment above, just for clarification-
12:16 AM Ticket #420 (Scope bug or mis-wording in documentation) updated by anonymous: >I would expect it to behave like we wrote it. Because, you know, we wrote AutoIt and it's not VB. Maybe that's your problem? You're expecting AutoIt to be something or behave like something it isn't. I made no particular assumptions for what you'd expect as a developer per-se. However, I would think most programmers would find this very counter-intuitive and non-standard compared to other languages. I don't expect it to behave exactly like VB either, nor would I want it too. There are programming conventions that are followed by nearly every modern language though, and I think having a local scope as a pseudo-global scope deviates from this... I can't think of another language that treats it as such off the top of my head. >Except that AutoIt doesn't have scope blocks other than "Global" and "Function" level scope. I know :( >Nothing needs done. Everything is working exactly how it's intended to. Your expectations are wrong. That's always your decision, I can only recommend you not be so dismissive about it, I only point it out because I personally think it would be better for AutoIt, but I'd at least encourage discussion about this among you developers... The end choice is always yours. From a programmers perspective though, this would really be one of the only things of AutoIt that just seem 'wrong' in its public implantation.

Jul 1, 2008:

10:35 PM Ticket #422 (_GDIPlus_GraphicsSetSmoothingMode Failure) closed by Gary: Fixed: Fixed in version: 3.2.13.4
8:12 PM Ticket #422 (_GDIPlus_GraphicsSetSmoothingMode Failure) updated by WeaponX: Just for added clarification, the code I posted draws 8 sets of diagonal lines. The values tested were from 0-7. Attempting to use dllcall with GdipSetSmoothingMode throws an error for values greater than 4. The function _GDIPlus_GraphicsSetSmoothingMode2 is the same as in GDI.au3 except it passes $iMode directly instead of converting it with Switch...EndSwitch.
4:44 PM Ticket #422 (_GDIPlus_GraphicsSetSmoothingMode Failure) updated by Valik: Description changed
3:12 PM Ticket #422 (_GDIPlus_GraphicsSetSmoothingMode Failure) created by WeaponX: Calling _GDIPlus_GraphicsSetSmoothingMode($hGraphics, 2) returns FALSE …

Jun 30, 2008:

11:08 PM Ticket #420 (Scope bug or mis-wording in documentation) updated by Valik: Replying to evilertoaster: > I would expect it to behave like VB 2005 not VB 6.0 (which was generally considered non-standard) as defined here- > http://msdn.microsoft.com/en-us/library/bybkyxaz(VS.80).aspx I would expect it to behave like we wrote it. Because, you know, we wrote AutoIt and it's not VB. Maybe that's your problem? You're expecting AutoIt to be something or behave like something it isn't. > It it generaly more accepted to have variables be local when delcared inside thier own 'block'. I would highly recommend looking at this agian. Except that AutoIt doesn't have scope blocks other than "Global" and "Function" level scope. Nothing needs done. Everything is working exactly how it's intended to. Your expectations are wrong.
10:12 PM Ticket #420 (Scope bug or mis-wording in documentation) updated by evilertoaster: I would expect it to behave like VB 2005 not VB 6.0 (which was generally considered non-standard) as defined here- http://msdn.microsoft.com/en-us/library/bybkyxaz(VS.80).aspx It it generaly more accepted to have variables be local when delcared inside thier own 'block'. I would highly recommend looking at this agian.
9:42 PM Ticket #421 (Error in reading status of Radio Button) closed by Valik: No Bug: This belongs on the support forum. Also, we've never claimed support for .NET controls so even more reason this isn't a bug. If you need help, use the forum.
9:18 PM Ticket #421 (Error in reading status of Radio Button) updated by WeaponX: We will need more information to reproduce the error. What program is MyTestApp? What language? Is it really a radio control or simulated using buttons and graphics?
9:04 PM Ticket #421 (Error in reading status of Radio Button) created by tim@…: I am trying to read the state of a Radio button on my form. […] …
8:07 PM Ticket #420 (Scope bug or mis-wording in documentation) closed by Valik: No Bug: It is created with local scope. And local scope at the global level means the variable is globally visible. What else would you expect? Not a bug, doesn't need documented, just need user's to turn their brains on and think things through for once.
7:53 PM Ticket #420 (Scope bug or mis-wording in documentation) created by evilertoaster: As shown in this thread- …
4:19 PM Ticket #419 (FileInstall - tip for path to source in current directory) closed by Valik: Completed: Added in version: 3.2.13.4
2:00 PM Ticket #419 (FileInstall - tip for path to source in current directory) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
1:48 PM Ticket #419 (FileInstall - tip for path to source in current directory) updated by WeaponX: You shouldn't even need that: FileInstall("sourcefile.ext", $DestLocation)
12:06 PM Ticket #419 (FileInstall - tip for path to source in current directory) created by Zedna: Please add this tip into AutoIt helpfile at FileInstall: Prefixing …

Jun 28, 2008:

2:35 PM Ticket #418 (GUICreate: $WS_EX_LAYERED documentation error) closed by Gary: No Bug: Changed example 2, extended styles are not BitOr'ed. Also changed comment to: ; transparent MDI child window Don't think the documentation needs to be changed. Setting as no bug.
2:21 PM Ticket #418 (GUICreate: $WS_EX_LAYERED documentation error) updated by Gary: It uses it in an MDI Child Window not a Normal Child window The example needs to be changed tho. The extended styles should be bitor'ed together not added.
1:07 PM Ticket #418 (GUICreate: $WS_EX_LAYERED documentation error) created by kenn: "$WS_EX_LAYERED Creates a layered window. Note that this cannot be …

Jun 27, 2008:

11:36 PM Ticket #415 (CUI compiled scripts won't execute batch files properly) updated by ResNullius: Replying to Valik: >That's because when running non-compiled, you are not running as a console application at all. So, this is irrelevant. Just background info, didn't want to be accused of insufficient testing :-) >That being said, I know what the issue is and how to fix it but I'm debating on whether or not fixing it is right. Of course, that is up to you. If you decide not to fix, will you explain why it isn't right to? Just seems to me that if a compiled GUI script can execute batch files like this OK then a CUI compiled one should be able to also. Thanks Valik, I'll leave you alone now.
11:18 PM Ticket #417 (Changing function parameters on a function call) closed by Gary: No Bug: Not a part of the Standard UDFs either.
11:14 PM Ticket #417 (Changing function parameters on a function call) updated by serg: Sorry, it's not a bug, my mistake.
11:09 PM Ticket #417 (Changing function parameters on a function call) created by serg: The folowing script consists of two files: HTTP_UDF.au3: […] And …
10:05 PM Ticket #415 (CUI compiled scripts won't execute batch files properly) updated by Valik: Owner, Status changed
4:35 PM Ticket #416 (Ability to Hide all errors (or write them to a log)) closed by Valik: Rejected: There are a number of reasons I'm closing this as rejected. First, I have in a private list details regarding a better error-reporting system. Second, you can already achieve "silent errors" by ensuring the scripts are invoked with /ErrorStdOut. This forces all errors to go to the stdout stream which will have the end result of the errors not being seen by the user. Third, your script shouldn't have errors in it in the first place, and there are plenty of tools to prevent them. The only errors in a script that are terminal are syntax errors or out of memory. If there are any other terminal error messages they likely need removed.
4:24 PM Ticket #415 (CUI compiled scripts won't execute batch files properly) updated by Valik: Replying to ResNullius: > The following script when run uncompiled behaves as expected, you are greeted with the "Press any key to continue" message and the batch file waits for a key press. That's because when running non-compiled, you are not running as a console application at all. So, this is irrelevant. > Tested on Win2000/XP 32-bit with all service packs. Also with AutoIt beta 3.2.13.3. > The problem does not exist when compiled under v3.2.10.0 (with a compatible version of AutoIt3Wrapper). The first version to officially support CUI compilation is 3.2.12.0. Any other version is irrelevant. That being said, I know what the issue is and how to fix it but I'm debating on whether or not fixing it is right.
4:15 PM Ticket #414 (Better OnAutoItStart/OnAutoItExit handling) updated by Valik: Summary changed
I agree, the way both OnAutoItStart and OnAutoItExit are implemented is absolute rubbish and needs re-designed from the ground up to facilitate more than one handler being registered without complex chaining by the user. I'm renaming the ticket to better reflect the content.
4:00 PM Ticket #416 (Ability to Hide all errors (or write them to a log)) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
2:59 PM Ticket #416 (Ability to Hide all errors (or write them to a log)) created by anonymous: The reason I ask for this is for the company I work for, one of the …
2:51 PM Ticket #415 (CUI compiled scripts won't execute batch files properly) created by ResNullius: The following script when run uncompiled behaves as expected, you are …
2:00 PM Ticket #414 (Better OnAutoItStart/OnAutoItExit handling) updated by TicketCleanup: Version, Milestone changed
Automatic ticket cleanup.
1:59 PM Ticket #414 (Better OnAutoItStart/OnAutoItExit handling) created by anonymous: I propose to add multiple OnExitFuncs, so that you can easily clean up …
7:09 AM Ticket #383 (Include A3X file as a script) updated by willi_chan@…: As the original poster, let me say that I do not think that including an exe would be practical, but either an A3X, or some new compiled form that includes function interfaces is needed. I am also working on some scripts that create and use keycode files to handle scritps that need to include authentication, but I cannot share the scripts or allow anyone else to use the routines without negating the security. The ability to include compiled function libraries becomes more and more necessary with each project I take on.

Jun 26, 2008:

6:27 PM Ticket #412 (HotKeys do not function if explorer.exe is not running.) closed by Valik: No Bug: Wow, you really didn't think about this one at all. Replying to caplan77: > Hotkeys work only when explorer.exe is running (a user is logged into the PC). This is simply not true. I just shut down Explorer and run a test script. Hotkeys worked just fine. > Hotkeys do not work at the logon prompt (no user logged on, explorer.exe not running). > > I've written a screen saver in AutoIt and would like hotkeys to work when just winlogon.exe is running. I'm sure this is either a security feature or due to the script running under a different session. In either case, I fully expect this behavior. > Hotkeys do not work if the user locks the workstation while logged in. Because it's locked? Wouldn't it be rather insecure if a locked workstation still allowed hotkeys to execute arbitrary code? Definitely no bugs here.
6:21 PM Ticket #413 (GUICtrlHotKeySet -Hot key input box GUI control.) closed by Valik: Duplicate: Search the issue tracker before posting. Closing as duplicate of #311 (Still rejected).
6:00 PM Ticket #413 (GUICtrlHotKeySet -Hot key input box GUI control.) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
5:05 PM Ticket #413 (GUICtrlHotKeySet -Hot key input box GUI control.) created by Caplan77: Autoit has hotkey functions & gui functions but no way to easily set …
4:50 PM Ticket #412 (HotKeys do not function if explorer.exe is not running.) created by caplan77: Hotkeys work only when explorer.exe is running (a user is logged into …
4:40 PM Ticket #387 (Change DllCallbackFree() to check handle validation or erase it) updated by Valik: Version, Type changed
Jon, from the sounds of it, this is the same thing you used to have in place when an invalid file handle was passed to FileClose(). Remember how it used to throw up an error and stop the script? Remember how I bitched about that? Oh, and this crashes AutoIt. Stupid, yes, but I was trying to generate something simple to reproduce the bug and ended up with a hard-crash: […] Incidentally, flagging this as a bug, not a feature request.
11:43 AM Ticket #387 (Change DllCallbackFree() to check handle validation or erase it) updated by Jon: I don't understand.
11:42 AM Ticket #386 (Notification about "Announcements and Site News" on Italian) closed by Jon: Wont Fix: Forum bug. Generally we don't touch these and wait for the next bugfix/release.
11:41 AM Ticket #408 (inetGet will not download from https with bad certificate) updated by Jon: Owner, Status changed
We'll add a flag to ignore cert errors.

Jun 25, 2008:

11:38 PM Ticket #337 (TraySetIcon causes read only error) updated by Valik: I just looked over the code. There's no permission issue anywhere. In fact there are no permissions used at all. Reading the icon is done via a standard Windows API function for reading icons.
11:02 PM Ticket #337 (TraySetIcon causes read only error) updated by Queue: It's not AV related, as there's no AV of any sort installed on the machine I've been testing this on. The error message is as follows (it's a Windows error that is not specific to AutoIt): AutoIt v3: ScriptName.exe - Write Protect Error The disk cannot be written to because it is write protected. Please remove the write protection from the volume VOLUME NAME in DRIVELETTER:. Cancel &Try Again &Continue The same error is triggered by many other programs when attempting to open a file on the read-only device, but not EVERY file open triggers it; I suspect it's related to the permissions requested when opening the file for access. One way around this, as odd as it sounds, is to make a simple program with NSIS that simply launches the AI3 compiled script; for whatever reason that suppresses the error messages (it does for any other program that's triggering the error as well). This fix isn't inherited though, as a program then launched by the AI3 compiled script can still trigger the error. A Flash Drive with a read-only switch (with the switch set to read-only) and WinXP Pro SP3 running as Administrator are the general specifics; I honestly can't provide better details, it's as generic of a (legitimate) Windows install as could be. Nothing's running in the background aside from the usual (lsass, csrss, smss, winlogon, services, explorer; the only non default services are for .NET and an ATI video card and all of the ATI services are set to disabled). Anyhow, leaving it as closed since if you can't reproduce it there's not much you can do. Queue
8:07 PM Ticket #411 (Topmost option) closed by Valik: Rejected: What you want is highly specific and not very useful. See _WinAPI_SetWindowPos() for manipulating the Z-Order to your heart's content. Closing as rejected.
8:00 PM Ticket #411 (Topmost option) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
7:57 PM Ticket #411 (Topmost option) created by anonymous: I'd like to be able to set a window on top incrementally. Meaning, if …
7:09 PM Ticket #410 (Have installation of Scite editor optional) closed by Valik: Rejected: Redirect the .au3 extension to use a different ProgID (For example, I use "AutoIt3ScriptCustom"). Then the AutoIt installer will still change the "AutoIt3Script" ProgID but since the .au3 extension points to "AutoIt3ScriptCustom" the changes won't be reflected. You can, of course, customize whatever commands you want in your own ProgID. This is basically a one-time customization. Closing as rejected.
6:39 PM Ticket #410 (Have installation of Scite editor optional) created by BillY: I am an UltraEdit and PSPad user and whenever I install AutoIt I have …
3:14 PM Ticket #409 (Checkbox check goes to Select Case while not programmed to do so) closed by J-Paul Mesnage: No Bug
3:13 PM Ticket #409 (Checkbox check goes to Select Case while not programmed to do so) updated by J-Paul Mesnage: in fact when you delete first gui and recreate a new one the controlid of the new one are the same as the one of the first one so your msg loop will getevent and the corresponding old code will be executed
3:07 PM Ticket #409 (Checkbox check goes to Select Case while not programmed to do so) created by Triblade: First, this script is a copied script of somebody I tried to help url: …
10:55 AM Ticket #399 (Advanced Mode with GuiCtrlRead for Context Menu) closed by J-Paul Mesnage: No Bug
10:52 AM Ticket #399 (Advanced Mode with GuiCtrlRead for Context Menu) updated by dgz: Sorry, It's the first time I run Beta, and believed it replace the old version. It's ok with 3.2.13.3. Thanks
10:38 AM Ticket #399 (Advanced Mode with GuiCtrlRead for Context Menu) updated by Gary: 3.2.13.3 works for me. Are you sure you ran it in beta? […]
10:29 AM Ticket #399 (Advanced Mode with GuiCtrlRead for Context Menu) updated by dgz: I tried with 3.2.13.3 beta but it's still the same. @Valik: here is a sample script: ^{#include <GUIConstantsEx.au3>} ^{Opt("GUIOnEventMode", 1)} ^{GUICreate ("Test", 200, 200)} ^{$contextmenu = GUICtrlCreateContextMenu()} ^{GUICtrlCreateMenuItem ("Item 1", $contextmenu)} ^{GUICtrlSetOnEvent (-1, "ItemInfo")} ^{GUICtrlCreateMenuItem ("Item 2", $contextmenu)} ^{GUICtrlSetOnEvent (-1, "ItemInfo")} ^{GUICtrlCreateMenuItem ("Item 3", $contextmenu)} ^{GUICtrlSetOnEvent (-1, "ItemInfo")} ^{GUICtrlCreateMenuItem ("Item 4", $contextmenu)} ^{GUICtrlSetOnEvent (-1, "ItemInfo")} ^{GUISetState ()} ^{While 1} ^WEnd ^{Func ItemInfo ()} ^{MsgBox (0,0,GUICtrlRead(@GUI_CtrlId,1))} ^EndFunc

Jun 24, 2008:

7:01 PM Ticket #322 (SciTE wrong highlighting when using nested #CS/#CE) closed by Jos: Fixed: Fixed in version: 3.2.13.4
7:00 AM Ticket #408 (inetGet will not download from https with bad certificate) created by bart.wical@…: https://www.fnmoc.navy.mil/ww3_cgi/dynamic/ww3.b.spac.sig_wav_ht.000.gi …
4:59 AM Ticket #383 (Include A3X file as a script) updated by Valik: There are much much better ways of going about that than what you suggest. The "correct" way is to establish some sort of inter-process communication. Then provide a library file with an API plugins can use in their plugin-script to interact with the main program. In short, AutoIt can not help you with what you want to do. Your suggestion makes no sense and does not solve the problem you wish to solve.
4:44 AM Ticket #383 (Include A3X file as a script) updated by anonymous: Would the more generic nature of the original ticket summary be entirely out of the question? That is, would it be impossible to also allow compiled EXE files to be included as well? (Naturally, the only EXEs that would work would be those compiled scripts that are not UPX'd) The rationale behind this is that I have a compiled executable whose functionality I'm considering allowing users to extend via their own scripts. I could always distribute an A3X file and have them download AutoIt (or maybe even do some FileInstall procdedure), but then that quickly becomes very clunky, especially when I make use of custom icon resources added to the executable directly.
4:24 AM Ticket #403 (Different results for both for loops) closed by Valik: No Bug: Ultima brings up a good point. One that needs documented. As a result I've created #407 and am closing this as no bug.
4:24 AM Ticket #407 (Document For...In is read-only for AutoIt arrays) created by Valik: We need to document that when using an AutoIt array with For...In, the …
4:11 AM Ticket #403 (Different results for both for loops) updated by Ultima: @OP: By any chance, have you bothered to try printing $Array1[0]? You'd easily notice that it *is* an empty string, even after the loop. What you don't seem to realize is that the "For ... In ... Next" loop is for read-only purposes, only. Setting $Item inside the loop does not set the corresponding element in $Array, as you apparently seem to think. As such, this doesn't look at all like a bug to me.
2:00 AM Tickets #405,406 batch updated by TicketCleanup: Milestone changed
Automatic ticket cleanup.
12:56 AM Ticket #406 (GUI include file bug!) closed by Valik: No Bug: Bad enough that you posted once, but twice? Once again: http://www.autoitscript.com/forum/index.php?showtopic=34658
12:54 AM Ticket #405 (GUI bug) closed by Valik: No Bug: http://www.autoitscript.com/forum/index.php?showtopic=34658
12:46 AM Ticket #406 (GUI include file bug!) created by blade_quest@…: The single line in any Auto-It script I write is picked up by many …
12:42 AM Ticket #405 (GUI bug) created by blade_quest@…: The single line in any Auto-It script I write is picked up by many …

Note: See TracTimeline for information about the timeline view.

Download in other formats:

RSS Feed