Timeline
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 …
Mar 6, 2011:
- 12:22 PM Ticket #1892 (eventlog) updated by
- Solved, "$iOffset += StringLen($aStrings[$iI])*2 + 2" ;; suggested change works fine. Other suggested changes i did not test. A lot of thanks
- 11:34 AM Ticket #1892 (eventlog) updated by
- 2 other suggestions/fixes ... (only tested on "(Language:0409 Keyboard:00000409 OS:WIN_XP/Service Pack 3 CPU:X86 OS:X86)") […] […]
- 3:14 AM Ticket #1892 (eventlog) updated by
- Seems someone forgot to adjust the offset counter to count wchar's instead of single byte chr's. […]
- 3:00 AM Ticket #1894 (gimagex for AIK 3.0) updated by
-
Version changed
Automatic ticket cleanup. - 2:42 AM Ticket #1894 (gimagex for AIK 3.0) created by
- I am trying to use gimagex with waik 3.0 and it does not seem to work.
Mar 5, 2011:
- 12:38 PM Ticket #1889 (_ArrayDisplay optionaly display columns in hex.) updated by
- I think to display in hex is only one way to display the real values even those changed by display functions. The current version didn't display as is, it displays only what would be displayed, due to interpreting control characters. Results of a any StringRexExp to re-format only to see what is really there is not very convenient, but anyway.
- 12:11 AM Ticket #1893 (#Include-All) updated by
- Don't seems something that really adds something generally useful to AutoIt's core, or something that can't be done with some (run-before-compile) user script. or, […]
Mar 4, 2011:
- 10:28 PM Ticket #1893 (#Include-All) created by
- I would like to see a new pre-compiler directive, #Include-All. Syntax …
- 6:14 PM Ticket #1892 (eventlog) updated by
- How this is a bug of EventLog3.au3 that is part of autoit I thought that its a bug and i had post here. Sorry, Now I post on http://www.autoitscript.com/forum/topic/126175-eventlog-description
- 4:53 PM Ticket #1892 (eventlog) updated by
- > Hi, I have a problem with eventlog.au3 > Can you help me? Nope. This section is for Bug-reports ... ONLY. For user problems there is the Forum Section. -> http://www.autoitscript.com/forum
- 4:46 PM Ticket #1892 (eventlog) created by
- Hi, I have a problem with eventlog.au3. when I use _eventlog_read() …
- 8:16 AM Ticket #1889 (_ArrayDisplay optionaly display columns in hex.) updated by
- _ArrayDisplay() main function it to display the array data as it is. Any special re-formatting of the array data falls outside its main purpose. (or: user-code should take care of that before feeding the array(adjusted copy) to _ArrayDiplay().)
Mar 3, 2011:
- 9:00 PM Ticket #1891 (_ArrayDisplay (......,i$iTranspose,...) wrong description ?) updated by
-
Version changed
Automatic ticket cleanup. - 7:54 PM Ticket #1891 (_ArrayDisplay (......,i$iTranspose,...) wrong description ?) created by
- Bug in help of _ArrayDisplay: ---- $iTranspose [optional] If set …
- 6:23 PM Ticket #1890 (Add _WinAPI_GetParent in _WinAPI_GetAncestor related-section) created by
- And vice versa
- 6:00 PM Ticket #1889 (_ArrayDisplay optionaly display columns in hex.) updated by
-
Version changed
Automatic ticket cleanup. - 5:49 PM Ticket #1889 (_ArrayDisplay optionaly display columns in hex.) created by
- Feature reuest for function: _ArrayDisplay(Const ByRef $avArray .... …
Note:
See TracTimeline
for information about the timeline view.
