Timeline
Feb 2, 2012:
- 4:40 PM Ticket #2119 ("_EventLog__Open" can not access additional Windows 7/2008 eventlogs) created by
- Hi, it seems that Autoit can only access the "standard" eventlogs …
- 1:55 PM Ticket #2118 (bug when launching a command Line program using @SW_HIDE) updated by
- An example is SciTE editor which does not honor
- 5:22 AM Ticket #2118 (bug when launching a command Line program using @SW_HIDE) closed by
- No Bug: It's an application's choice whether it honors the show flag or not. Most applications do, some do not.
- 2:58 AM Ticket #2118 (bug when launching a command Line program using @SW_HIDE) updated by
- Care to provide a real-world failing example? Which error do you get?
Feb 1, 2012:
- 8:21 PM Ticket #2118 (bug when launching a command Line program using @SW_HIDE) created by
- Using the command run(a"_command_line_program.exe", @ScriptDir, …
Jan 31, 2012:
- 6:53 AM Ticket #2117 (Improved _FileCountLines()) updated by
- I would like to point out jchd had a modified proposal Spiff59's that removes all memory limitations here: http://www.autoitscript.com/forum/topic/137024-modified-filecountlines/page__view__findpost__p__958820
Jan 30, 2012:
- 12:25 AM Ticket #2115 (Installer/Uninstaller issues) updated by
- I've been slightly wrong about all this. My auto-update script was the reason installations were going to C:\Program Files\AutoIt3 so my fault there. However, the AutoIt installer should still detect a previous install and it should detect I'm not installing to the same directory as that previous install so it should warn me/let me remove the orphaned installation.
- 12:19 AM Ticket #2115 (Installer/Uninstaller issues) updated by
- I just updated to 3.3.8.1 using silent install and it ignored the x86 install at C:\Program Files (x86)\AutoIt3 and put itself at C:\Program Files\AutoIt3. Not right.
Jan 29, 2012:
- 9:49 PM Milestone 3.3.8.1 completed
- 9:00 PM Ticket #2117 (Improved _FileCountLines()) updated by
-
Version changed
Automatic ticket cleanup. - 8:50 PM Ticket #2117 (Improved _FileCountLines()) updated by
- I guess this could have been a "Bug" rather than "Feature request". Further testing shows the existing function rarely reports the same number of lines as a file opened any editor (Notepad, SciTE, etc) as it strips all trailing whitespace. An extra test is required to properly handle EOF. This is my final, fully-tested (really!) version... […]
- 8:06 PM Ticket #2117 (Improved _FileCountLines()) updated by
- Poop on me! I tested without all the frills in the production version (edits, error handling, etc). When I added all the fluff after testing, I should have re-tested. The SRER version of this does not require the StringStripWS call, in fact it cuases the function to report 1 less line than exist in the file. The StringStripSW() sneeds to be removed. This SRER version also does not suffer from the problem reported in tracker #1831. It correctly reads beyond a line containing a NUL, and processes the test file from that ticket correctly.
- 7:50 PM Ticket #2117 (Improved _FileCountLines()) updated by
- Do fix the "terminated with linefeed terminated" comment ;) I decided it sounded better to have "terminated" as the first word on the 2 comments, but failed to delete the trailing instance of the word from the end of the linefeed comment. Thanks.
- 7:47 PM Ticket #2117 (Improved _FileCountLines()) created by
- The following version of _FileCountLines() is 60-70% faster than the …
- 5:10 PM Ticket #2116 (random() is not random) closed by
- No Bug: Please go learn about pseudo-random number generators and seeding. Everything you describe is exactly what I expect and what anybody who understands how a pseudo-random number generator works should expect. No bug here. Not in AutoIt, at least.
- 11:19 AM Ticket #2116 (random() is not random) created by
- There seems to be a bug if you use random() in multiple simultanously …
- 10:16 AM Ticket #1970 (Bug added to internal __FTP_ListToArray()) closed by
- Fixed: Fixed by revision [6735] in version: 3.3.9.0
- 12:34 AM Ticket #2068 (ACos() bug) closed by
- Fixed: Fixed by revision [6733] in version: 3.3.9.0
- 12:25 AM Ticket #2101 (Help not opening on Windows XP) closed by
- Works For Me: Works for me. I guess. I don't know, there's very little information here to diagnose the problem. Possibly related to some known SciTE-Lite issues that are fixed.
- 12:24 AM Ticket #2083 (AU3Record.exe error "missing MSVCR100.dll" when trying to run it) closed by
- Fixed: Fixed by revision [6730] in version: 3.3.9.0
Jan 28, 2012:
- 10:54 PM Ticket #2115 (Installer/Uninstaller issues) updated by
- Actually this is even more confusing than I realized. For some reason it seems 3.3.8.0 silently installed in 64-bit mode which is why it left an orphaned 32-bit 3.3.6.1 laying around. When I uninstalled 3.3.6.1 I broke some registry entries so I had to re-install 3.3.8.0 and I explicitly chose the 32-bit version to be the default so it went to the 32-bit location. We really need to do some checks on 64-bit systems to make sure only one version is installed. If attempting to upgrade/reinstall to the other version it should ask to remove the soon-to-be-orphaned version. Now I have to go through, uninstall two separate versions of 3.3.8.0 and then install it again just to ensure everything is sorted out. Crazy.
- 10:44 PM Ticket #2115 (Installer/Uninstaller issues) created by
- The installer for 3.3.8.0 installed to C:\Program Files\AutoIt3 on …
- 9:13 PM Ticket #1698 (GUICtrlSetLimit, limit 32767) updated by
- @Melba23 Works perfect Thnx Best Regards, Emiel
- 1:35 PM Ticket #1698 (GUICtrlSetLimit, limit 32767) updated by
- But this does: […]
- 10:08 AM Ticket #2073 (ContinueLoop crashes script if nothing to jump) updated by
-
Description changed
- 10:07 AM Ticket #2073 (ContinueLoop crashes script if nothing to jump) updated by
-
Description changed
- 10:07 AM Ticket #2073 (ContinueLoop crashes script if nothing to jump) updated by
-
Description changed
Jan 27, 2012:
- 2:31 PM Ticket #1970 (Bug added to internal __FTP_ListToArray()) updated by
- I am working on it I attach my proposed solution
- 9:54 AM Ticket #1970 (Bug added to internal __FTP_ListToArray()) updated by
- This Bug was not fixed in Release of 3.3.8.0 hope it will be in 3.3.9.0, Quite important!
- 1:19 AM Ticket #2113 (AU3Check misinterprets some object's property names as AI keywords) closed by
- Fixed: Fixed by revision [6725] in version: 3.3.9.0
Jan 26, 2012:
- 9:38 AM Ticket #2114 (Performance increase to _ArrayDisplay()) updated by
- >>Don't fully understand why not redrawing something which is not an displayed windows as an perf impact. I agree and have been kinda wondering the same thing. I was always under the impression if a window was minimized or not visible, the redraw would not happen. >>Not sure such big length of arraydisplay is something we have to optimized. ok then :(
- 7:21 AM Ticket #2114 (Performance increase to _ArrayDisplay()) updated by
- Don't fully understand why not redrawing something which is not an displayed windows as an perf impact. But well it has. Not sure such big length of arraydisplay is something we have to optimized. The user will take sometime to look at …
Jan 25, 2012:
- 9:00 PM Ticket #2114 (Performance increase to _ArrayDisplay()) updated by
-
Version changed
Automatic ticket cleanup. - 7:00 PM Ticket #2114 (Performance increase to _ArrayDisplay()) updated by
- Sounds good E
- 6:00 PM Ticket #2114 (Performance increase to _ArrayDisplay()) created by
- I notice today that _arraydisplay() does not disable redraw before …
- 10:50 AM Ticket #2112 (Running debugger window and clicking close script window makes this ...) updated by
- This ticket is referenced in revision: [6714]
- 10:44 AM Ticket #2112 (Running debugger window and clicking close script window makes this ...) closed by
- Fixed: Fixed by revision [6713] in version: 3.3.9.0
- 5:55 AM Ticket #2056 (Excel.au3 - 5 Broken Functions) updated by
- not sure it was not a NO BUG as we cannot reproduce without a repro script.
- 1:49 AM Ticket #2113 (AU3Check misinterprets some object's property names as AI keywords) created by
- AU3Check raises an error on object's property names which are also …
Jan 24, 2012:
- 10:23 PM Ticket #2056 (Excel.au3 - 5 Broken Functions) closed by
- Fixed: Even though the issue is not directly addressed, it's fixed in next beta as collateral.
- 7:39 PM Ticket #2109 (ProcessList and WinList should accept Default or -1) reopened by
- Replying to MrCreatoR <mscreator@…>: > It's the same, it will not return all processes/windows list. Perhaps it's a bug (if you say it should work). Without looking the code probably does something different when there are no parameters. What that means is the function doesn't support any form of default behavior so adding Default isn't just filling in missing functionality but adding new functionality. > And it's not about me been lazy (it's not in my nature :) ), this is about inconsistency with other functions that accept Default, and we talking about [optional] parameter. Look at many of the cases where Default is supported. It's in places where you want to skip parameters so you can access later parameters. For example, in WinMove() you might use Default for width so you can specify a new height. In this case you are asking for Default to exist on the only parameter the function takes (in the case of ProcessList()). So no, it's really not inconsistent. I'll re-open this merely to remind myself to look and see what is going on with the functions. I'm still not convinced supporting Default is really useful for these functions.
- 4:44 PM Ticket #2112 (Running debugger window and clicking close script window makes this ...) updated by
- In fact it is working as intended from my point of view. When you click close the script is waiting you close the output "report Log" windows to allow you to visualize what occurs instead of closing the "report Log" debug windows. Perhaps a last message could have been out saying that the script will quit only when the output "report Log" window will be closed.
- 2:49 PM Ticket #2112 (Running debugger window and clicking close script window makes this ...) updated by
- It seems that this was first reported and fixed here http://www.autoitscript.com/trac/autoit/ticket/1588 but has now reappeared. M23
- 2:07 PM Ticket #2112 (Running debugger window and clicking close script window makes this ...) created by
- Running GUI created from your "Example GUI" works ok, but if debugger …
- 12:11 PM Ticket #2109 (ProcessList and WinList should accept Default or -1) updated by
- Replying to Valik: >To specify an default parameter for a string you use "" It's the same, it will not return all processes/windows list. Perhaps it's a bug (if you say it should work). And it's not about me been lazy (it's not in my nature :) ), this is about inconsistency with other functions that accept Default, and we talking about [optional] parameter.
- 7:45 AM Ticket #2056 (Excel.au3 - 5 Broken Functions) updated by
- missing a repro script Thanks
Jan 23, 2012:
- 11:33 PM Ticket #2111 (RunAs broken when Authenticated Users added to Replace a process level ...) updated by
- Doh. We'll call this an oversight on my part. To be fair, I'm not really sure where this would be documented. You have the right privileges but they are disabled. They must be enabled before they can be used. Pretty trivial for AutoIt to do that, of course. I didn't realize it was necessary because the SYSTEM account always has those privileges enabled.
- 10:12 PM Ticket #2111 (RunAs broken when Authenticated Users added to Replace a process level ...) updated by
- !! Also requires Authenticated Users be added to 'Adjust memort quotas for a process' to fail.
- 9:49 PM Ticket #2111 (RunAs broken when Authenticated Users added to Replace a process level ...) created by
- We have an application that adds 'Authenticated Users' to 'Replace a …
- 7:22 PM Ticket #2110 (autoit.exe -> autoit.exe + autoit.dll) updated by
- It's clear you selectively read. Yes, it's possible under very specific circumstances to share a DLL. Very specific circumstances. The off-shoot of that is you introduce he risk DLL Hell if you have more than one version of AutoIt installed. Which is going to be every single user of the beta. I don't know about other people but I have compiled scripts in more than one directory. That means I would have more than one DLL location which means either DLL Hell or I gain NOTHING from your suggestion. Further more, one of the biggest aspects of AutoIt is that it's stand-alone. This breaks that. The only way to keep AutoIt stand-alone is to use tricks to load the DLL ourselves which defeats your stupid idea. Do you really have so many AutoIt processes running at a given time to make this worthwhile? I don't. I don't have enough AutoIt processes running when I build AutoIt and there can be half a dozen or more instances of AutoIt running in our build scripts. This is an incredibly stupid request. It's based on ignorance and complete lack of understanding of AutoIt, AutoIt's design principles and how Windows works. Furthermore it is completely irrelevant. The cost of a typical computer now-a-days is about 2 weeks with average salary. Computers from 15 years ago can still run AutoIt easily. We don't have a bloated, dependency-laden application and you want to break that because you're worried about a few MB of memory? Let's play with numbers. I have 8GB of memory which is pretty standard. What the fuck do I care if AutoIt uses 8MB per process? That's 0.09765625% of my available memory. Lots of people have multiple GB of memory. Even an old machine with paltry 512MB still equates to only 1.5625% of total memory for a single AutoIt process. Even if we figure in 384MB for OS use on a 512MB system we can still easily run 16 simultaneous AutoIt processes. That's without even considering the OS will disk swap so we really can run more than that. I'm a developer of AutoIt. Do you know how many times I've had 16 simultaneous AutoIt processes running? Only when I accidentally introduce a recursive Run() loop into my program causing it to spawn copies of itself. In other words, I've never intentionally had that many running despite having an elaborate build system setup for AutoIt that makes liberal use of process isolation. Your request has zero merit.
- 3:45 PM Ticket #2092 (ShellExecuteWait() receiving incorrect error levels on Windows XP.) updated by
- Workaround: Use the RunWait function (Run doesn't return error levels directly). /B flag doesn't appear to influence the outcome in any way. Modify Step 3 as follows: […] Expected Results: 5 Actual Results: 5
- 9:06 AM Ticket #2110 (autoit.exe -> autoit.exe + autoit.dll) updated by
- First DLL's not only save hard drive space but above all save space in MEMORY. Use AutoIt3.exe to run .a3x files use of AutoIt3.exe involves the use of many autoit3.exe those scripts . Instead the use of DLL involves the use of a single dll and many autoti3.exe but that are minimal because it only loads the dll. Secondary, if more than one process is using a DLL at the same time, they share the DLL's code. http://en.wikipedia.org/wiki/DLL_Hell#Shared_in-memory_modules http://www.autoitscript.com/forum/topic/45009-autoitexe-autoitexe-autoitdll/page__view__findpost__p__362790 However, if you continue to insult forget.
- 1:09 AM Ticket #2110 (autoit.exe -> autoit.exe + autoit.dll) updated by
- You're an idiot. There's really no easier way I can put it. You're reading something you don't understand and taking it out of context. DLL's save hard drive space because only one copy needs to exist. Okay, we have that. Use AutoIt3.exe so you only have one runtime engine rather than compiling your scripts to duplicate the runtime engine. We've solved that problem already. As JP also mentions, you can compile your scripts to a special format so they aren't plain text. So score one for your stupidity in missing features that already exist. Second, memory. DLL's can be loaded on-demand thus saving memory when the DLL isn't needed. Newsflash genius, a DLL of AutoIt would need to be loaded for an AutoIt script to execute - at all. So guess how much memory you save? None! You're operating under the mistaken assumption that all scripts will reference a single DLL loaded into memory. That is incorrect. Windows isolates each process into it's own virtual address space and that includes loading new, pristine copies of DLL's from disk into the new process' address space. In other words, you aren't saving memory. You're just asking us to needlessly complicate the language and it's use for a really ridiculous reason. Hard drive and memory space has never been an issue with AutoIt. We occasionally get some stupid fuck like you who doesn't find that good enough. They usually meet me and I tell them to fuck off. So fuck off.
Jan 22, 2012:
- 10:49 PM Ticket #1485 (Hard crash with ContinueCase) closed by
- Fixed: Fixed by revision [6671] in version: 3.3.9.0
- 10:20 PM Ticket #2110 (autoit.exe -> autoit.exe + autoit.dll) updated by
- In fact you may use the .a3x compilation which allow you to have only one executable for all scripts.
- 9:34 PM Ticket #2110 (autoit.exe -> autoit.exe + autoit.dll) updated by
- DLL stands for "Dynamic Link Library." A DLL (.dll) file contains a library of functions and other information that can be accessed by a Windows program. If a dynamic link is created, the .dll files will only be used when needed. Dynamic links help programs use resources, such as memory and hard drive space, more efficiently. DLL files can also be used by more than one program. It is possible for you , you try to answer as clean (anal, piss, stupid, ridicule, ...).
- 9:30 PM Ticket #2095 (_FTP_ListToArrayEx Helpfile Typo) closed by
- Fixed: Fixed by revision [6669] in version: 3.3.9.0
- 8:28 PM Ticket #2073 (ContinueLoop crashes script if nothing to jump) closed by
- Fixed: Fixed by revision [6668] in version: 3.3.9.0
- 8:25 PM Ticket #2109 (ProcessList and WinList should accept Default or -1) closed by
- Rejected: The functions will never accept -1 because -1 is a number. To specify an default parameter for a string you use "". There is some merit to accepting the Default keyword. However your usage case just boils down to I'm too lazy to write If $param = Default Then $param = "" before you pass it to a function so I'm not inclined to make changes to the language itself to save you a single line of code.
- 8:22 PM Ticket #2110 (autoit.exe -> autoit.exe + autoit.dll) closed by
- Rejected: If you're going to get anal over the size of AutoIt then piss off and write everything in assembly so you can control every byte. You're missing the point of a high level language if you aren't willing to sacrifice a bit of size and performance for a lot of convenience. Also, I don't think Windows works how you think it does. Each process is going to load their own copy of the DLL so it's still going to take up memory even with your stupid idea. Lastly. Greater than 1GB of memory? I've used more than 1GB of memory for 5 years or more. I have 8GB of memory and that's about average now-a-days I think. Your "complaint" is really about a decade too late and it was as irrelevant then as it is now. Ticket rejected with extreme prejudice (and ridicule).
- 5:02 PM Ticket #2092 (ShellExecuteWait() receiving incorrect error levels on Windows XP.) closed by
- No Bug: This is not bug on our side. AutoIt is correct about return value. What you should do is try exit batch without /B flag. This looks like cmd.exe bug on XP. Oh yes and... if you want to run batch file then don't use ShellExecute functions, use Run functions so that you know for sure what will happen.
- 12:00 PM Ticket #2110 (autoit.exe -> autoit.exe + autoit.dll) updated by
-
Version changed
Automatic ticket cleanup. - 10:33 AM Ticket #2110 (autoit.exe -> autoit.exe + autoit.dll) created by
- I like the idea about autoit to be separated in one dll, and a small …
- 10:12 AM Ticket #2088 (_ArrayDisplay not handling Default parameters correctly) closed by
- Fixed: Fixed by revision [6664] in version: 3.3.9.0
- 4:19 AM Ticket #2108 (_Singleton leaves an open handle) closed by
- No Bug: Do you actually understand what the singleton pattern is? 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. The function is already broken by returning anything at all. My original version exited but somebody who doesn't know what they are doing thought it would be a great idea to break the pattern for whatever asinine reason it was changed. Now you want to further break the function by further modifying already broken behavior? No, if I consent to any change to this function it will be to restore it back to it's true singleton pattern implementation. Closing as no bug.
Jan 21, 2012:
- 9:00 PM Ticket #2109 (ProcessList and WinList should accept Default or -1) updated by
-
Version changed
Automatic ticket cleanup. - 8:46 PM Ticket #2089 (_IEFormSubmit gives WEnd^ ERROR) updated by
- Replying to trancexx: > This is clear bug in IE.au3... > I'll try to find out who is responsible for the situation. DaleHohm is creator of IE UDF.
- 6:28 PM Ticket #2109 (ProcessList and WinList should accept Default or -1) created by
- When we use ProcessList or WinList with Default keyword or with -1, …
- 5:26 PM Ticket #2108 (_Singleton leaves an open handle) created by
- It creates a mutex, however if the named mutex already exists, it gets …
Jan 20, 2012:
- 7:33 PM Ticket #1656 (Object not being released properly) closed by
- No Bug: This is not a bug. Proper handling for this particular "problem" is described inside the help file. Search it using this "stop rerouting events object is still holding a reference". Use Stop method of the event object before releasing it.
Jan 19, 2012:
- 8:21 PM Ticket #2089 (_IEFormSubmit gives WEnd^ ERROR) updated by
- This is clear bug in IE.au3. It's unbelievable that code can be as dumb and at the same time that no one had reported the issue before. I'll try to find out who is responsible for the situation.
- 5:13 PM Ticket #2078 (Error in com expression) closed by
- Fixed: Fixed by revision [6654] in version: 3.3.9.0
- 3:59 PM Ticket #2089 (_IEFormSubmit gives WEnd^ ERROR) updated by
- I have the same error with Windows 7 and IE8. My code is : ; Ouvrir une page Internet Explorer avec l'URL XXXXXXX $sURL = "XXXXXXXXXXXX" $oIE = _IECreate($sURL) ; Cliquer sur le lien correspondant pour poursuivre navigation (certificat) _IELinkClickByText($oIE, "Poursuivre avec ce site Web (non recommandé).") sleep(1000) _IELinkClickByText($oIE, "Click here to sign in again") sleep(1000) ; Saisir les informations de connexion et envoyer le formulaire $o_form = _IEFormGetObjByName($oIE, "frmLogin") $o_login = _IEFormElementGetObjByName($o_form, "username") $o_password = _IEFormElementGetObjByName($o_form, "password") _IEFormElementSetValue($o_login, "XXXXXXXXXX") _IEFormElementSetValue($o_password, "XXXXXXXXXXX") _IEFormSubmit($o_form) Sleep(1000) Thank you for your correction
- 12:53 PM Ticket #2097 (Performance problem with acces to object (Excel object)) updated by
- Sorry ma English is not so good. Result is, that access Excel object via COM interface is much slower in 3.3.8.0 than in 3.3.6.1 Maybe there is relationship with bug http://www.autoitscript.com/trac/autoit/ticket/2002
- 12:15 PM Ticket #2097 (Performance problem with acces to object (Excel object)) updated by
- I think this ticket must be analyse carefully as Michal is right when he say the results are the same under 3.3.6.1 and 3.3.8.0 just the speed differ.
- 10:23 AM Ticket #2097 (Performance problem with acces to object (Excel object)) updated by
- Replying to trancexx: > Versions before 3.3.8.0 were broken. Don't compare speed of broken thing with a speed of non-broken thing. The result you get when you do that is not valid. So you think that it is correct, that in newest version (3.3.8.0) is access to Excel via COM much more slower (10 ms) than in previous version (3.3.6.1), where the access speed was about 1 ms?
Jan 18, 2012:
- 9:01 PM Ticket #1257 (Fix bugs in Static array handling) closed by
- Fixed: Fixed by revision [6653] in version: 3.3.9.0
- 9:01 PM Ticket #1257 (Fix bugs in Static array handling) updated by
- Will use ReDim to redim.
- 6:11 PM Ticket #2097 (Performance problem with acces to object (Excel object)) closed by
- No Bug: Versions before 3.3.8.0 were broken. Don't compare speed of broken thing with a speed of non-broken thing. The result you get when you do that is not valid.
- 6:06 PM Ticket #2107 (Virus Warnings) closed by
- No Bug: Please use your head.
- 1:40 PM Ticket #2107 (Virus Warnings) created by
- I got warnings about viruses in AutoIt. Compiling doesn't work any …
- 6:58 AM Ticket #2098 (_ArraySearch and StringInStr Problem / Bug?) closed by
- No Bug: As stated by anonymous you must go to the forum first to get help. This is a bug reporting place not a forum. Your script is incomplete how do you declare $DNSServer and $infoarr? missing 2 Next's and the #include you use
- 4:22 AM Ticket #2106 (Document how to insert newlines (multi-line strings) in ClipPut, Send etc.) closed by
- Rejected: You are missing something. A couple things. First, it is documented how to insert newlines. Second, this is not the forum. You should have asked for help on the forum where you would have been directed to the correct location in the documentation.
- 3:00 AM Ticket #2106 (Document how to insert newlines (multi-line strings) in ClipPut, Send etc.) updated by
-
Version changed
Automatic ticket cleanup. - 1:10 AM Ticket #2106 (Document how to insert newlines (multi-line strings) in ClipPut, Send etc.) created by
- I'm new to AutoIt, so forgive me if I'm missing something. From my …
Jan 17, 2012:
- 7:59 PM Ticket #2098 (_ArraySearch and StringInStr Problem / Bug?) updated by
- Did you post this in the general help forum first? I believe the issue is in your code.
- 5:23 AM Ticket #2104 (Lost the Titles on all my open folders after a lot of shell/resize ...) updated by
- UPDATE 3 Hey sorry about that! I had a really bad programming day yesterday! I re-imaged my computer, and reported a bug that did not exist except in my head! Worst of all, i apparently did not read the ticket guidelines earnestly enough! I've since got a handle on the situation: 1. If you look at the code above, you can see that the number of parameters is not right for the WinMove function. That's why i was "suddenly" not able to move folder windows by the name method anymore. That's when i noticed for the first time that my folders did not have visible titles like everything else. So i thought i had messed them up and jumped to conclusions. I would not have re-imaged my computer if i wasn't sincere...and also having a bad programming day (sounds better than 'very dumb'). 2. The reason i could not move some PDF is because i was shelling them by shortcuts whose names were not matching the actual filename of the file they pointed to! Don't make this mistake! So there is really NO ISSUE with PDF files. They can be moved as easily as any other window. 3. I should be using @error checking to abort operations (using Exit) so that i don't have to click Tools>Stop Executing 4. I'm happy to report everything works fine with WinMove using either the name or class method. 5. Thanks for a great program! Don't kick me out just because i'm a newb!
- 4:37 AM Ticket #2103 (compiles autoit) closed by
- Rejected: Couldn't be bothered to search the forum first where this has been shot down about three hundred thousand times, eh?
- 4:35 AM Ticket #2105 (Odd behavior Hex()) closed by
- No Bug: You want the forum, not the issue tracker.
Jan 16, 2012:
- 6:45 PM Ticket #2105 (Odd behavior Hex()) updated by
- Results from sample script $DecimalNumber >1862402120< $fromRegistry >1862402120< 1862402120 = 1862402120 Hex($DecimalNumber) >6F020048< Hex($fromRegistry) >41DBC08012000000<
- 6:26 PM Ticket #2105 (Odd behavior Hex()) created by
- AutoIt 3.3.8.0 XP SP3 I have recompiled a script using latest AutoIt …
- 5:33 PM Ticket #2104 (Lost the Titles on all my open folders after a lot of shell/resize ...) updated by
- You clearly did not read the ticket guidelines before posting. If you choose to use our forum do not make the same mistake of not reading our rules. After this egregious display of disregard for the purpose of this issue tracker I will not hesitate to make you go away should you break our forum rules. Use your brain in the future.
- 3:02 PM Ticket #2104 (Lost the Titles on all my open folders after a lot of shell/resize ...) closed by
- No Bug: Before reporting a bug use forum to have help. It is not true that windows 7 has no title. Certainly bug in your script
- 2:54 PM Ticket #2096 (_FTP_ListToArrayEx $Return_Type = 1 or 2 no Array Content) closed by
- Duplicate: at the time 1499 was fix it was as suggested definitly some subsequent posts was added to identified new bug. That the reason why 1970 was open. don't open a new ticket for the same bug
- 2:15 PM Ticket #2096 (_FTP_ListToArrayEx $Return_Type = 1 or 2 no Array Content) updated by
- A corrected version of the function was first appended to ticket 1499. When that ticket was completed without fixing the issue, ticket 1970 was opened (and remains open). We're waiting for the fix in 1499 to be put into production.
- 8:34 AM Ticket #2104 (Lost the Titles on all my open folders after a lot of shell/resize ...) updated by
- UPDATE 2 Ok, no wunder i couldn't find anything on the web... Apparently folders in Windows 7 don't have titles! Duh! Had not really noticed that before! However... I'm still having trouble manipulating Adobe Reader files using the name method. What kicked this off is i was usually successful moving folders with the name method... ...and then suddenly i couldn't. That's when i noticed the "missing" titles and jumped to conclusions. Probably it had something to do with just being worn out with all the tests i was running to get PDF files to respond to the name method. That's just not happening.
- 3:39 AM Ticket #2104 (Lost the Titles on all my open folders after a lot of shell/resize ...) updated by
- UPDATE: I restored my disk image from three days ago, and guess what? I still don't have folder titles back! So the mystery thickens. I feel like i walked into the twilight zone.
- 3:35 AM Ticket #2104 (Lost the Titles on all my open folders after a lot of shell/resize ...) updated by
- I've been working on opening several files of different types with ShellExecute, and then doing what i can to WinMove them into exact positions on my desktop using the names of the titles. After a lot of trial and error, i lost the titles on my folders (CabinetWClass). That's right, i have no titles in the title bar of any folder i now open in Windows 7 x64 ! System restore did not work, and poking around in folder view options (ie. restoring everything to default) did not work. Googling around the web also did not produce anything. I probably won't be able to reproduce this for anyone, except to inline the kind of code i was fooling around with...every possible variation of the lines included...to see why i was not able to control my Adobe Reader PDF files consistently using the name in their title bars. I've finally given up and have decided to WinMove all my files around using their class. I have no problem with the class method, but the name-of-title method is inconsistent. When i was testing, i'd get a lot of stalling. The script would not go forward, nor would the script end, so i'd have to click Stop Executing alot. The thing is, whenever i'd do that, it seems like there were still commands in a que looking for files or folders to mess with, and i'd see things popping up on my desktop where it looked like some code was still trying to execute. I just crossed my fingers it would not harm anything. But after a lot of this, it somehow managed to turn the titles off (make them invisible?) on all my folders, so i can't control those with the name method. I can still control them with the class method though. I have a disk image from three days ago that i'll be restoring my laptop to the way it was. That's the only solution i can think of to get my titles back. And from now on i'll be using the class method, even though it was not my first choice. So beware, and good luck! Code: […]
- 1:53 AM Ticket #2104 (Lost the Titles on all my open folders after a lot of shell/resize ...) updated by
- I've been working on opening several files of different types with ShellExecute, and then doing what i can to WinMove them into exact positions on my desktop using the names of the titles. After a lot of trial and error, i lost the titles on my folders (CabinetWClass). That's right, i have no titles in the title bar of any folder i now open in Windows 7 x64 ! System restore did not work, and poking around in folder view options (ie. restoring everything to default) did not work. Googling around the web also did not produce anything. I probably won't be able to reproduce this for anyone, except to inline the kind of code i was fooling around with...every possible variation of the lines included...to see why i was not able to control my Adobe Reader PDF files consistently using the name in their title bars. I've finally given up and have decided to WinMove all my files around using their class. I have no problem with the class method, but the name-of-title method is inconsistent. When i was testing, i'd get a lot of stalling. The script would not go forward, nor would the script end, so i'd have to click Stop Executing alot. The thing is, whenever i'd do that, it seems like there were still commands in a que looking for files or folders to mess with, and i'd see things popping up on my desktop where it looked like some code was still trying to execute. I just crossed my fingers it would not harm anything. But after a lot of this, it somehow managed to turn the titles off (make them invisible?) on all my folders, so i can't control those with the name method. I can still control them with the class method though. I have a disk image from three days ago that i'll be restoring my laptop to the way it was. That's the only solution i can think of to get my titles back. And from now on i'll be using the class method, even though it was not my first choice. So beware, and good luck! Code: […]
- 1:49 AM Ticket #2104 (Lost the Titles on all my open folders after a lot of shell/resize ...) created by
- I've been working on opening several files of different types with …
Jan 15, 2012:
- 9:00 PM Ticket #2103 (compiles autoit) updated by
-
Version changed
Automatic ticket cleanup. - 8:45 PM Ticket #2083 (AU3Record.exe error "missing MSVCR100.dll" when trying to run it) updated by
- I've the same poblem on Windows xp sp3 with no visual studio installed.
- 8:27 PM Ticket #2103 (compiles autoit) created by
- I have a suggestion that I hard to do, but that is great: It would be …
- 12:55 PM Ticket #2099 (Crash of script when using "_GUICtrlDTP_SetSystemTimeEx()" function) updated by
- Replying to Jpm: > Can you post a full repro script? > Thanks Hi, this is a little bit difficult because the script uses an internal database for data management. I will see if I can downgrade this script to a usable and functional scriptlet. Thanks.
- 8:14 AM Ticket #2099 (Crash of script when using "_GUICtrlDTP_SetSystemTimeEx()" function) updated by
- Can you post a full repro script? Thanks
- 1:16 AM Ticket #2100 (Windows On ARM Compiler (WOA)) closed by
- Rejected: Your ticket is a question. This is not a place to ask questions.
Jan 14, 2012:
- 11:07 PM Ticket #2102 (error using ContinueLoop) closed by
- Duplicate
- 10:54 PM Ticket #2094 (Hex() returns incorrect values) closed by
- No Bug
- 10:26 PM Ticket #2102 (error using ContinueLoop) updated by
- Oh, thanks, I didn't see that ticket.
- 10:19 PM Ticket #2102 (error using ContinueLoop) updated by
- See ticket #2073 which this one duplicates.
- 10:18 PM Ticket #2102 (error using ContinueLoop) updated by
- For the last example I forget to paste defined functions. […]
- 10:07 PM Ticket #2102 (error using ContinueLoop) created by
- When using code like […] I receive an error […] Full example …
- 8:50 PM Ticket #2089 (_IEFormSubmit gives WEnd^ ERROR) updated by
- Replying to Jpm: > Just an info Win7 x86/IE9 run OK Did you provide a valid gmail username/password? The error is only given after a succesfull login.
- 3:13 PM Ticket #2101 (Help not opening on Windows XP) created by
- Just update on new version ( autoit-v3-setup - v.3.3.8.0 ) If i click …
- 12:00 AM Ticket #2100 (Windows On ARM Compiler (WOA)) updated by
-
Version changed
Automatic ticket cleanup.
Jan 13, 2012:
- 9:09 PM Ticket #2100 (Windows On ARM Compiler (WOA)) created by
- Has the subject of a WOA compiler been broached. I work for a large …
- 12:25 PM Ticket #2099 (Crash of script when using "_GUICtrlDTP_SetSystemTimeEx()" function) created by
- The script crashes when "_GUICtrlDTP_SetSystemTimeEx()" is used in …
- 10:13 AM Ticket #2094 (Hex() returns incorrect values) updated by
- Ok, I understand why it is given the different output. I think this will break many scripts, but if this is the correct implementation, than that is the price we have to pay for it. Once all scripts/UDF's are fixed, this is no issue anymore. This ticket can be closed.
- 9:40 AM Ticket #2094 (Hex() returns incorrect values) updated by
- The hex change in 3.3.8.0 make support of all internal type. Previously double seems to be converted to integer. It may be a script breaking but the new behavior is the correct one no internal change to var type. it you want to be convinced that not just not return the left 4 just try […]
- 9:20 AM Ticket #2098 (_ArraySearch and StringInStr Problem / Bug?) created by
- Hi, iam not sure but i think we found a Bug in _ArraySearch and/or in …
- 9:08 AM Ticket #2094 (Hex() returns incorrect values) updated by
- Replying to Jpm: > In fact displaying an integer does not mean that the internal value is an integer. > In this specific case the division by 2 make the internal result a double. > So when you get part of the representation of a double is not the the same a getting part of an integer. > You can see that Hex(..., n) is taking the right n bytes of the hex internal represention. > NO BUG And how do you explain the difference in output between version v3.3.6.1 and v3.3.8.0? v3.3.8.0 […] v3.3.6.1 […] Additionally, it make no sense that Hex(8/2,2) results in 00 I still think this is a BUG.
- 9:06 AM Ticket #1397 (HotKeySet not working when default keyboard layout set as non-english) updated by
- I think Autoit does not have the responsability to change the locale. If the user want, he can do it as you did. what the fix did was to report the failure in the @error if I remember.
- 8:53 AM Ticket #2094 (Hex() returns incorrect values) updated by
- In fact displaying an integer does not mean that the internal value is an integer. In this specific case the division by 2 make the internal result a double. So when you get part of the representation of a double is not the the same a getting part of an integer. You can see that Hex(..., n) is taking the right n bytes of the hex internal represention. NO BUG
- 8:41 AM Ticket #2094 (Hex() returns incorrect values) updated by
- Replying to enaiman: > I did a bit of testing and it is not Hex fault. > > I found that StringLen does not return an integer - see example: > > > {{{ > $string = "aaaa" > > $var = StringLen($string)/2 > MsgBox(0, "$var - StringLen", $var) > MsgBox(0, "Hex $var", Hex($var, 2)) > > $var = int(StringLen($string)/2) > MsgBox(0, "$var - Int(StringLen)", $var) > MsgBox(0, "Hex $var", Hex($var, 2)) > }}} > > When Transforming the result using "Int", everything works as intended. Not true stringlen is ok but as you divide by 2 you get a float/double in $var
- 7:02 AM Ticket #2094 (Hex() returns incorrect values) updated by
- Replying to enaiman: > I did a bit of testing and it is not Hex fault. > > I found that StringLen does not return an integer - see example: > > > {{{ > $string = "aaaa" > > $var = StringLen($string)/2 > MsgBox(0, "$var - StringLen", $var) > MsgBox(0, "Hex $var", Hex($var, 2)) > > $var = int(StringLen($string)/2) > MsgBox(0, "$var - Int(StringLen)", $var) > MsgBox(0, "Hex $var", Hex($var, 2)) > }}} > > When Transforming the result using "Int", everything works as intended. Not entirely convinced: […] and it does not explain next outcome […]
Jan 12, 2012:
- 11:54 PM Ticket #2094 (Hex() returns incorrect values) updated by
- I did a bit of testing and it is not Hex fault. I found that StringLen does not return an integer - see example: […] When Transforming the result using "Int", everything works as intended.
- 3:08 PM Ticket #2097 (Performance problem with acces to object (Excel object)) created by
- There is performance problem with access into Excel object in AutoIT …
- 3:04 PM Ticket #2096 (_FTP_ListToArrayEx $Return_Type = 1 or 2 no Array Content) created by
- If the Flag for the $Return_Type is set to 1 or 2 the array does not …
- 2:54 PM Ticket #2095 (_FTP_ListToArrayEx Helpfile Typo) created by
- Just a little Typo... as seen n the picture :)
- 2:32 PM Ticket #2094 (Hex() returns incorrect values) updated by
- Problem is introduce in v3.3.8.0 With v3.3.6.1 all calls return 4 (or 04) running this on Windows 7 32-bit
- 2:24 PM Ticket #2094 (Hex() returns incorrect values) created by
- running next script gives incorrect values (always expecting 4) […]
Jan 11, 2012:
- 9:28 PM Ticket #2087 (IniWrite & IniReadSection bug) updated by
- Actually the help file says: When writing a value that is quoted, the quotes are stripped. In order to write the quote marks to the value, you must double up the quoting. For example: ""This is a test"" will produce "This is a test" in the file. (this is from IniWrite in the help file) The help file says nothing about reading values with quotes, just writing them. So, it does strip the quotes, but if they're doubled, the quotes are included in the information written.
Jan 9, 2012:
- 3:09 AM Ticket #2093 (DllStructGetSize reports wrong size) closed by
- No Bug: jchd is correct. Closing as no bug.
Jan 8, 2012:
- 1:55 PM Ticket #2093 (DllStructGetSize reports wrong size) updated by
- Wrong assumption. Alignment and padding make 8 the right size for this struct. This question belongs to the Help Forum, not here.
- 6:17 AM Ticket #2093 (DllStructGetSize reports wrong size) created by
- $test = DllStructCreate("dword;char") ConsoleWrite("size …
Jan 7, 2012:
- 9:00 PM Ticket #2069 (StringRegExpGui example produce 2 warnings) updated by
-
Milestone changed
Automatic ticket cleanup. - 7:16 PM Ticket #2069 (StringRegExpGui example produce 2 warnings) closed by
- Fixed
- 11:42 AM Ticket #1772 (InetGet reload from the remote site) updated by
- No real idea, At least this ticket is No Bug for me. For your simulation I am not an expert on such impact of what etc is doing Sorry for not helping more
- 11:15 AM Ticket #1772 (InetGet reload from the remote site) updated by
- Yeah, I got the same problem here. I think the AV doesn't like redirecting google hostname. I deactivated the AV, and got the same results. With google.com address (not working) the result is not null, but with autoitscript.com it's. Do you think InetGet/InetRead should follow the hosts guideline, or it's not a proper way to test the forced reload option? This question was raised when I was working in a code for detecting a webpage modification. I thought the redirection would simulate a change. The solution was the substitution of InetRead for WinHTTP. Now, I'm not really sure about that. It works for some urls but not for others.
- 10:33 AM Ticket #1772 (InetGet reload from the remote site) updated by
- Your not working example is producing a Virus warning SettingsModifier:Win32/PossibleHostsFileHijack as the modification of etc is detected by antivirus "MS Security essential"
- 10:29 AM Ticket #2092 (ShellExecuteWait() receiving incorrect error levels on Windows XP.) updated by
- Same with 3.3.8.0 It needed to check with latest Beta/release in case of
- 9:39 AM Ticket #1772 (InetGet reload from the remote site) updated by
- Just to be clear about the WinHTTP solution. I did two examples here, one that does work, giving a null source code, and one that does not. Before running the examples, make sure you have the WinHTTP UDF. It can be found here: http://winhttp.origo.ethz.ch/wiki/winhttp Example working: http://pastebin.com/6SvHBjmH Example not working: http://pastebin.com/M9JQwJr0
- 3:18 AM Ticket #1772 (InetGet reload from the remote site) updated by
- Well, I used a packet sniffer to check if two "GET requests" are done. They are. For some reason,the second request doesn't use the new Ip Address (Localhost). But, when the program is re-executed (with hosts still implying in the redirection), it resolves autoitscript.com hostname as localhost. I wrote a similar one with WinHTTP. The same problem happens. I don't quite understand how the re-execution forces the hostname resolution to localhost.
- 12:04 AM Ticket #1772 (InetGet reload from the remote site) updated by
- I wrote an example script in order to prove that InetRead does get data from cache, even when it's set to force a reload. http://pastebin.com/pLT0vJkf In my PC, I get the same data from both InetRead. It should not happen after the hostname is redirected to localhost. The data should be null. There are many threads of people complaining about this issue. I don't think it's an isolated problem.
Jan 6, 2012:
- 9:05 PM Ticket #2092 (ShellExecuteWait() receiving incorrect error levels on Windows XP.) created by
- Description: Executing a file through ShellExecuteWait() will result …
- 2:52 PM Ticket #1772 (InetGet reload from the remote site) updated by
- In fact I conduct experiment with some accessible file under www.autoitscript.com and it was successful provided you wait the end of the download. The first example is asking for a background download so sometime is needed before completion. my environment is 3.3.8.0 (Language:040C Keyboard:0000040C OS:WIN_7/Service Pack 1 CPU:X64 OS:X86)
- 2:34 PM Ticket #1772 (InetGet reload from the remote site) updated by
- Not sure to understand, with the first script I get a file whose time is changing. That does not mean it has been updated as the contain is the same. Cannot you update the link so it will point to a real changing file. Thanks
- 12:09 PM Ticket #1772 (InetGet reload from the remote site) updated by
- I'm running AutoIt version 3.3.8.0 and got the same problem. I wrote a script to check a website's source code modification. I tried to use InetGet, InetRead and _InetGetSource (which uses InetRead with force reload parameter). I put all of these functions inside an infinite while loop, displaying the source. I executed the program with the correct IP for the hostname. Changing the hosts file (@WindowsDir\system32\drivers\etc) in order to redirect the hostname to localhost (127.0.0.1), the source code displayed does not vanish. Only when I reboot the program, it is possible to get a null source code. It is not a Windows issue, my browser cannot load the page with disabled cache.
Jan 5, 2012:
- 10:51 PM Ticket #2087 (IniWrite & IniReadSection bug) updated by
- Help-file says that if you read quoted text from ini file - quotes go away because they are simply used for values containing whitespaces. But when reading section with quoted values - you get quote signs. Help file doesn't say a word about that. I don't think that it's help-file bug, rather it's the IniReadSection bug.
- 7:59 PM Ticket #2091 (Au3Check and non-ANSI files) updated by
- BOM Check with proper error notification added to au3check. Support/workaround for files with BOM is already implemented in AutoIt3Wrapper. Jos
Jan 4, 2012:
- 11:46 PM Ticket #1760 (#OnAutoItStartRegister, ignores single quoted function names.) reopened by
- Re-opening. We should do this because it's expected that strings can be single- or double-quoted.
- 10:01 PM Ticket #1397 (HotKeySet not working when default keyboard layout set as non-english) updated by
- Here is the fix i use: […]
- 9:57 PM Ticket #1397 (HotKeySet not working when default keyboard layout set as non-english) updated by
- And again, it's not fixed.
- 7:43 AM Ticket #2083 (AU3Record.exe error "missing MSVCR100.dll" when trying to run it) updated by
- In fact the adaptation to Visual studio 10 linkage was wrong. <StringPooling> has been set to true with no real reason
- 6:23 AM Ticket #2083 (AU3Record.exe error "missing MSVCR100.dll" when trying to run it) updated by
- May be due to the use of a x86-64 OS install, while the user has chosen to use x86 version of software. Solved by installing Visual C++ 2010 package for x86 (http://www.microsoft.com/download/en/details.aspx?id=5555) on a x86-64 box.
- 1:11 AM Ticket #2091 (Au3Check and non-ANSI files) updated by
-
Version changed
- 1:11 AM Ticket #2091 (Au3Check and non-ANSI files) created by
- Au3Check silently passes any non-ANSI file giving the illusion it has …
Jan 3, 2012:
- 12:40 PM Ticket #2088 (_ArrayDisplay not handling Default parameters correctly) updated by
-
Description, Summary changed
- 8:49 AM Ticket #2088 (_ArrayDisplay not handling Default parameters correctly) updated by
- Okay, I'm fine with your decision. So, if someone has an array with e.g. 10 columns, but he defines only 4 columns in the header parameter, he we'll only see those 4 columns displayed by _ArrayDisplay. FMPOV, this is a risk, because the function is a "debugging function" which should show as much information as possible (the complete array at all times). Anyhow, I accept that = no problem here. @trancexx: The only thing left now is, that the function doesn't deal correctly with the "Default" word as parameter which is briefly explained in the thread which I provided a link to in my first post. Nevertheless, I'll read the guidelines again a next time my ticket will be more correct.
- 6:58 AM Ticket #2089 (_IEFormSubmit gives WEnd^ ERROR) updated by
- Just an info Win7 x86/IE9 run OK
- 6:53 AM Ticket #2088 (_ArrayDisplay not handling Default parameters correctly) updated by
- Replying to BrewManNH: > _ArrayDisplay should never create a GUI larger than the width of the screen, in fact, it usually creates an undersized GUI compared to the ListView inside of it. In the _Array.au3 file, in which I modified a number of the array functions, one of the functions I modified was the _ArrayDisplay function so that it would autosize the GUI and the column widths because the current implementation of _ArrayDisplay doesn't do this currently. Even in my modification, the GUI will be at least 100 pixels smaller than the desktop on all sides regardless of screen resolution. > > Look in Example Scripts or in Feature Requests in Trac for a link to the _Array.au3 UDF I'm referring to. Thanks In fact I really think "default" keyword passing need to be corrected. But mananing the number of displayed columns by the $sheader is a real functionality. no header is displaying the total number of column so no bug for me.
Note:
See TracTimeline
for information about the timeline view.
