Timeline
Apr 6, 2011:
- 2:51 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by
- Ticket author is DaleHohm, forgot to enter my name at creation time.
- 1:34 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) created by
- With IE9 installed, the ObjName function returns an empty string when …
- 10:14 AM Ticket #1907 (Bug in AdlibRegister) updated by
- Think your right. Might already be solved with/by #1633 (Milestone: 3.3.7.0) Output on code below ... (comment). […] […]
- 6:02 AM Ticket #1907 (Bug in AdlibRegister) created by
- I think, there is a bug in AdlibRegister. I Register a function for …
Apr 4, 2011:
- 1:19 PM Ticket #1906 (reparse point) created by
- Please add detecting reparse point file attribute in FileGetAttrib().
- 4:35 AM Ticket #1904 (Problem with @MyDocumentsDir macro in Windows XP) closed by
- Works For Me
Apr 3, 2011:
- 9:00 AM Ticket #1905 (Dynamic Code Execution (like Exec in Python)) updated by
-
Version changed
Automatic ticket cleanup. - 6:03 AM Ticket #1905 (Dynamic Code Execution (like Exec in Python)) updated by
- Replying to hyperzap: > I was thinking (correct me if I am wrong) that, considering Autoit compiled scripts are just interpreter bundled with the script, that it might be practical to implement dynamic execution. This could help if say I was building a web server that used autoit scripts to build the HTML output, instead of calling the command line option it would be significantally faster to call an internal dynamic execute command. > > Something Like DynamExec( $LineArray) > or, if you didnt want to implement Control block logic, just > DynamExec( $LineString) > > Regards, > > Hyperzap Oh damn Im sorry I accidently opened it in the wrong catagory. My apologies again.
- 6:00 AM Ticket #1905 (Dynamic Code Execution (like Exec in Python)) created by
- I was thinking (correct me if I am wrong) that, considering Autoit …
Apr 1, 2011:
- 4:48 PM Ticket #1904 (Problem with @MyDocumentsDir macro in Windows XP) updated by
- Erm. That's definitively not doing it for me. Suggest you try the forum, as I think this is just a User-problem instead of a possible AutoIt-Bug.
- 11:33 AM Ticket #1904 (Problem with @MyDocumentsDir macro in Windows XP) updated by
- This script gives the error from first post: […] In this one I changed the order of edit operations on DCPlusPlus.xml file and the error is gone: […] What part from the first script cause the error ?
Mar 31, 2011:
- 11:50 PM Ticket #1904 (Problem with @MyDocumentsDir macro in Windows XP) updated by
- None reproducible, on clean windows (in virtual box) Environment(Language:0409 Keyboard:00000409 OS:WIN_XP/Service Pack 3 CPU:X86 OS:X86) Suspect local Windows settings issue, As @MyDocumentsDir (or the "My documents" folder location) is a User-changeable windows setting!
- 6:43 PM Ticket #1904 (Problem with @MyDocumentsDir macro in Windows XP) created by
- If I run the code bellow in Windows XP SP3 ENG, @MyDocumentsDir macro …
Mar 26, 2011:
- 3:39 PM Ticket #1903 (Au3Check, Globals, #OnAutoItStartRegister) created by
- Well, might as well drop this one in. (personal request of course) …
Mar 25, 2011:
- 7:50 PM Ticket #1902 (Better error msg for (undefined) Global var in Function definition.) updated by
- Replying to Valik: >You're full of contradictions. Yep. Recap: - To much risk (core code) for to little (questionable) benefit.
- 4:48 PM Ticket #1902 (Better error msg for (undefined) Global var in Function definition.) updated by
- Replying to mvg: > Replying to Valik: > > It tells you there is an error on line 2. From there you should be able to figure out on your own to at least look at the function definition on line X. > You mean Autoit is not made as a kind of easy low level skilled code language. > > > Quite simply, this is not worth the time and risk associated with changing the behavior. Won't you feel real daft if we fix this error message but totally break something else that was otherwise working correctly? > I did not know you where the timid kind when it comes to code. Timid? No, just smart enough to know not to fuck with something that's working if a change adds questionable benefit. > Nor do I see why I would need to feel daft for someone else his failure for adding error free code. It's called the law of unintended consequences. Besides, I didn't say it would take an error in the code to break behavior, only that behavior could break. Also, it occurs to me why should we care about your (and possibly others) inability to write error-free code when you clearly don't care about our (potential) inability to do so for a feature you (and only you) request? > Is that not why you have preliminary beta version's. To flush out major problems like that. Every single release there's a face-palmingly obvious bug missed. Every time. When you start messing around in the parser and lexer those bugs range from face-palmingly obviously to rather obscure and annoying. Obscure and annoying, much like this problem. > Anyway, where talking about a error message here. How is some code that is only going to be called when a terminal error is detected going to break something else in a significant way. > Its not like I suggested a rewrite of the error detection or something like that. If thats whats needed to be able to change this particular (ambigues in my view) error message. Just say so. Do you cut a man's chest open and poke around with his lungs just because he has a cough? No, you wait until you actually have a reason to go in there. The parser/lexer for AutoIt is the same way. If it doesn't need touched it doesn't get touched. This request does not fall into the "It needs touched" category. It's a rather obscure corner case that's unlikely to affect very many people. > Yep, It clearly is showing in which function definition to look for the problem. I can write bad code to demonstrate any problem I want and exaggerate it too. That doesn't make doing so a useful endeavor. > I think the Error message in these cases is ambiguous. And could use some improvement to make them less ambiguous and a lot more useful than there currently are. And considering AutoIt target audience I think its not such a stupid request as you like me to believe it is. You're full of contradictions. If the users are not as skilled as you imply then chances are they aren't going to be writing OnAutoItRegister stuff and if they use it at all it will be from 3rd party libraries which should already be written and tested properly by others. As for other conditions under which they can produce the problem, maybe they need to learn a little code structure. This bug would probably not affect me because I am unlikely to ever write code in such a fashion. If for some reason I did write such code then it would be trivial to fix because I write code iteratively so changes from my last working version to now are only a handful of lines making them easy to visually inspect. In other words, people need to learn a little bit about how to write and test code.
- 4:43 PM Ticket #1792 (ProcessExist or Maybe Run Command does not give the correct PID) updated by
- Thanks..
- 4:42 PM Ticket #1901 (Compiled 32bit scripts not working in system32 path on 64bit OS) updated by
- Hi Valik, My problem does not exist anymore.. Thanks Cheers Emiel
- 6:46 AM Ticket #1902 (Better error msg for (undefined) Global var in Function definition.) updated by
- Replying to Valik: > It tells you there is an error on line 2. From there you should be able to figure out on your own to at least look at the function definition on line X. You mean Autoit is not made as a kind of easy low level skilled code language. > Quite simply, this is not worth the time and risk associated with changing the behavior. Won't you feel real daft if we fix this error message but totally break something else that was otherwise working correctly? I did not know you where the timid kind when it comes to code. Nor do I see why I would need to feel daft for someone else his failure for adding error free code. Is that not why you have preliminary beta version's. To flush out major problems like that. Anyway, where talking about a error message here. How is some code that is only going to be called when a terminal error is detected going to break something else in a significant way. Its not like I suggested a rewrite of the error detection or something like that. If thats whats needed to be able to change this particular (ambigues in my view) error message. Just say so. > This is also very simple to avoid. Global variables should always appear near the top of a script either before or after all #include statements but before any code is ever executed. Yea, yea. And when you use #OnAutoItStartRegister I figure your not suppose to call functions that use any global variables. […] Yep, It clearly is showing in which function definition to look for the problem. Or: I think the Error message in these cases is ambiguous. And could use some improvement to make them less ambiguous and a lot more useful than there currently are. And considering AutoIt target audience I think its not such a stupid request as you like me to believe it is.
Mar 24, 2011:
- 8:12 PM Ticket #1792 (ProcessExist or Maybe Run Command does not give the correct PID) updated by
- This is not a bug. Here's what is happening. The version of mstsc.exe in SysWOW64 is 32-bits. When you run this version it just loads a 64-bit version of mstsc.exe. That means its PID changes and the problem you describe happens. I've verified that the version in SysWOW64 is 32-bits with Dependency Walker. I have also verified that running that version results in a 64-bit process running (Process Explorer). Also, that process is orphaned (It has no parent). If I run the version from system32 I also get a 64-bit process but it does have a parent - the Explorer process I launched it from. Now, this all relates to your specific case because you want to run the version in system32 explicitly and don't care that it's 64-bit. As you've discovered, the only way to do this from a 32-bit process is to briefly turn off redirection. My initial conclusion that this is not a bug stands. The only reason I'm explaining this now is because this ticket was referenced in #1901. I looked at this ticket, saw that I didn't provide a completely firm conclusion so I investigated something that came to me.
- 8:02 PM Ticket #1901 (Compiled 32bit scripts not working in system32 path on 64bit OS) updated by
- Emiel, I just saw your reply. It's a different issue. I now know what is causing your problem and will respond in the other ticket.
- 7:58 PM Ticket #1902 (Better error msg for (undefined) Global var in Function definition.) closed by
- Rejected
- 7:58 PM Ticket #1902 (Better error msg for (undefined) Global var in Function definition.) updated by
- It tells you there is an error on line 2. From there you should be able to figure out on your own to at least look at the function definition on line X. Quite simply, this is not worth the time and risk associated with changing the behavior. Won't you feel real daft if we fix this error message but totally break something else that was otherwise working correctly? This is also very simple to avoid. Global variables should always appear near the top of a script either before or after all #include statements but before any code is ever executed.
- 7:53 PM Ticket #1901 (Compiled 32bit scripts not working in system32 path on 64bit OS) updated by
-
Description, Summary changed
- 7:10 PM Ticket #1901 (Compiled 32bit scripts not working in system32 path on 64bit OS) updated by
- Forgot my name on the above message
- 7:09 PM Ticket #1901 (Compiled 32bit scripts not working in system32 path on 64bit OS) updated by
- I believe you mean this http://www.autoitscript.com/trac/autoit/ticket/1792
- 3:25 PM Ticket #1902 (Better error msg for (undefined) Global var in Function definition.) updated by
- > It might take some, more than needed, time to figure out the reported problem.
- 3:23 PM Ticket #1902 (Better error msg for (undefined) Global var in Function definition.) created by
- More informative error message for undefined vars(global) use in …
- 1:58 PM Ticket #1901 (Compiled 32bit scripts not working in system32 path on 64bit OS) created by
- Heavily re-written by Valik: 32-bit scripts do not run from …
Mar 20, 2011:
- 7:54 AM Ticket #1803 (GuiRichEdit Zoom Set) updated by
- ;---this needs to be modified---$r = _GUICtrlRichEdit_SetZoom($hRichEdit, 1/2)-------------- I think the problum may be SendMessage not sending integers ;----- Below works well---but does have to be reset after anything is streamed in------ ;----OK--------$r = _SendMessage($h_RichEdit, $EM_SETZOOM, $nominator, $denominator) ;$r = _SendMessage($hRichEdit, $EM_SETZOOM, 1000, 2333) ;--must be integer -- "1000, 2333" not "1, 2.333" ;$r = _SendMessage($hRichEdit, $EM_SETZOOM, 100, 200);-------eg 50% $r = _SendMessage($hRichEdit, $EM_SETZOOM, 1, 2);-------eg 50%
- 3:23 AM Ticket #1893 (#Include-All) closed by
- Rejected: We will not add bad features to facilitate lazy programming. Write your code well and a dangerous feature like this will not be necessary.
- 12:32 AM Ticket #1893 (#Include-All) updated by
- #Include-All and then on compile do a /striponly automatically, so that only relevant UDF's are kept. I think would work the best.
Mar 19, 2011:
- 4:05 PM Ticket #1900 (Improvements for StringRegExpGUI) created by
- Since I use that program a lot I noticed some bugs and ways to improve …
- 3:27 PM Ticket #1893 (#Include-All) updated by
- I don't think including really every include file would make sense. Also this would be possible by wildcasting them as "*.au3" which adds more flexibility. I'd make the "#include" able to interpret wildcasts, I don't see anything bad here.
- 3:00 PM Ticket #1899 (SendWindow) updated by
-
Version changed
Automatic ticket cleanup. - 12:55 PM Ticket #1899 (SendWindow) created by
- Allow keystrokes to be sent to a window regardless of it being active …
Mar 17, 2011:
- 5:03 PM Ticket #1893 (#Include-All) updated by
- I like the idea but not in the way the OP described. It could be just #Include-All without any wildcards and it could add ALL STANDARD UDFs.
Mar 11, 2011:
- 7:51 PM Ticket #1898 ($CmdLineRaw, not enforced as constant.) updated by
- (ps: no mention about const state of $CmdLine/$CmdLineRaw in "Command Line Parameters" help either.)
- 7:42 PM Ticket #1898 ($CmdLineRaw, not enforced as constant.) created by
- $CmdLineRaw, is not enforced as constant. ref: topic: $CmdLine is now …
- 9:04 AM Ticket #1897 (_DateDiff(), Suggestion (minor fix), Returns Double type instead of Int.) created by
- UDF: Date.au3 Issue: _DateDiff() returns Double type instead of Int …
Mar 10, 2011:
- 9:53 PM Ticket #1896 (Just a little error to fix in the help file (documentation)) created by
- In the AutoIT Help file on "Tutorials/Simple Notepad Automation" have …
Mar 8, 2011:
- 4:33 PM Ticket #1895 (Bugs in _GUIScrollBars_Init()) created by
- In _GUIScrollBars_Init(), when setting up the $tSCROLLINFO struct for …
Note:
See TracTimeline
for information about the timeline view.
