Timeline



Apr 21, 2011:

11:55 PM Ticket #1916 (Dealing with TAdvStringGrid, TPanel, TRichEdit, TFormMain, TTollbar) created by mailro
Can you add automation support for T components? Reading text, …
5:52 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by Valik
The only person here with ego is you. You apparently believe it is your place to determine bug severity for a project you do not administer. That is ego. Or stupidity. Possibly both. As for the rest of your comments, who cares. If you don't like me and are willing to put so much effort into avoiding a project I work on, be my guest. You're not going to take food off any of our tables (we are not paid for our work on AutoIt) nor are we going to lose any sleep over your decision to switch to another language. I think it speaks volumes about you that you are so petty as to do something like that. It also speaks volumes to me that you cannot for even a single second look at something you've said from a different perspective or stop and think that perhaps your attempt to be "helpful" in telling us how to manage our own project might be taken as condescending since it's our project and not yours. Anyway, I hope you leave and if so good riddance.
3:42 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by anonymous
Replying to dv8: > Instead of wasting everyone's time with your pointless comments just sit on your butt and wait for the fix quietly. And while you are on it, feel free to go to http://www.autoitscript.com/site/donate/ and make a donation like I just did (8PM98566LP724560B) to at least show some appreciation to the developers and all their hard work. What?!?! After being insulted, I'm asked to pay? If Valik's hadn't been so condescending, I would completely agree and consider making a contribution. Now, no way. I'll convert my entire organization to use another product, even if it's a commercial product, before I send one cent to AutoIt after this exchange. I've used dozens of freeware and open source products. I've contributed both code and money to an handful of them. I've been an active participant in all of their forums. With the exception of wxWidgets, I have never encountered this much ego, attitude, and conflict over absolutely nothing. > You guys ROCK! Please do not be discouraged from any anonymous replies. The product rocks. A few of the "guys" leave much to be desired.
3:20 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by anonymous
Replying to Valik: > You certainly weren't expecting "professional-level software development" to begin with since you felt the need to tell us this was important. Your post stating we should change the severity is akin to saying we are too stupid to make our own decisions and that its up to an anonymous poster to do it for us. Wow, you're putting a lot of words into my mouth. I did (and still do) expect professional software development practices. AutoIt would not have gotten this far without them. It's a shame you somehow inferred that I was calling you stupid from my simple request. Do you have self-esteem or sensitivity issues? Damn, I even said "Please".
7:26 AM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by dv8
Anonymous, even if you are a kid you should know that if you want a professional service (in any area) you should pay for it. All the people here are giving you their time for free and you are getting A LOT for your NOTHING! So your attitude is not appreciated at all! Instead of wasting everyone's time with your pointless comments just sit on your butt and wait for the fix quietly. And while you are on it, feel free to go to http://www.autoitscript.com/site/donate/ and make a donation like I just did (8PM98566LP724560B) to at least show some appreciation to the developers and all their hard work. You guys ROCK! Please do not be discouraged from any anonymous replies.

Apr 20, 2011:

11:13 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by Valik
You certainly weren't expecting "professional-level software development" to begin with since you felt the need to tell us this was important. Your post stating we should change the severity is akin to saying we are too stupid to make our own decisions and that its up to an anonymous poster to do it for us.
4:46 PM Ticket #1915 (Running script in SCITE doesnt work) closed by Jos
No Bug: Go to the forum for support. This is site is for reporting BUGs.
1:51 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by anonymous
Replying to Valik: > Yes, because updating the severity is certainly going to fix the problem. Typically in professional software development, issues with higher severity are fixed before those with lower severity. Based on Valik's reply to my comment, I guess I shouldn't expect professional-level software development practices out of the AutoIt development staff. Thanks for letting me know, Valik. Good one!
12:03 PM Ticket #1915 (Running script in SCITE doesnt work) created by matija@…
Hi, I install full instalation of AutoIt and when i put simple code in …
11:56 AM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by dv8
LOL :) Good one Valik! It's definitely not that serious, but now that IE9 is officially released and Windows is automatically updating it, I guess a lot of scripts will bomb out. :) I'm eagerly awaiting for this fix as well. I wish I could help with something…

Apr 19, 2011:

7:56 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by Valik
Yes, because updating the severity is certainly going to fix the problem.
4:27 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by anonymous
Please upgrade the severity. This problem breaks Internet Explorer automation using AutoIt. It's a very serious issue.
2:50 AM Ticket #1906 (reparse point) updated by Valik
The reparse data is not an attribute. If anything there needs to be a FileGetInfo() function to retrieve various bits of information about a file.

Apr 18, 2011:

9:01 PM Ticket #1914 (Error Codes for File operations) updated by GEOSoft
I forgot to mention that I am explicitly refering to FileCopy() and FileMove() here.
9:00 PM Ticket #1914 (Error Codes for File operations) created by GEOSoft
Right now the returned value for a failure contains nothing of any …

Apr 16, 2011:

5:08 PM Ticket #1913 (Mod() Crashing when divisor is zero.) closed by Jos
Duplicate: Duplicate report: https://www.autoitscript.com/trac/autoit/ticket/1660
4:30 PM Ticket #1913 (Mod() Crashing when divisor is zero.) created by Shaggi
Very simple. Mod(10,0) for example. Implement division by zero checking.

Apr 12, 2011:

10:22 AM Ticket #1912 (Run() does not work on x64 when compiled as x86) closed by Jos
No Bug: NoBug ... Use our Forum for support.
8:50 AM Ticket #1912 (Run() does not work on x64 when compiled as x86) created by Kasakie@…
This does not work on my 64bit Windows 7 OS. #Region ; Directives …
2:03 AM Ticket #1911 (_WinAPI_MsgBox) created by anonymous
Func _WinAPI_MsgBox($iFlags, $sTitle, $sText) BlockInput(0) …

Apr 9, 2011:

3:17 PM Ticket #1910 (Please change $TTN_GETDISPINFO to $TTN_GETDISPINFOW) created by anonymous
Please change in the example scripts for _GUICtrlToolbar_SetToolTips …

Apr 8, 2011:

12:28 PM Ticket #1909 (little problem with an updown control) created by anonymous
When I move the pointer over an input control the right border shows …

Apr 6, 2011:

2:51 PM Ticket #1908 (ObjName returns empty string for HTMLDocument with IE9) updated by DaleHohm
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 anonymous
With IE9 installed, the ObjName function returns an empty string when …
10:14 AM Ticket #1907 (Bug in AdlibRegister) updated by mvg
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 claudio.veronesi@…
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 xrewndel
Please add detecting reparse point file attribute in FileGetAttrib().
4:35 AM Ticket #1904 (Problem with @MyDocumentsDir macro in Windows XP) closed by Valik
Works For Me

Apr 3, 2011:

9:00 AM Ticket #1905 (Dynamic Code Execution (like Exec in Python)) updated by TicketCleanup
Version changed
Automatic ticket cleanup.
6:03 AM Ticket #1905 (Dynamic Code Execution (like Exec in Python)) updated by hyperzap@…
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 hyperzap
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 mvg
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 ffdshow
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 ?
11:25 AM DCPlusPlus.xml attached to Ticket #1904 by ffdshow
StrongDC++ settings file

Mar 31, 2011:

11:50 PM Ticket #1904 (Problem with @MyDocumentsDir macro in Windows XP) updated by mvg
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 ffdshow
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 mvg
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 mvg
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 Valik
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 anonymous
Thanks..
4:42 PM Ticket #1901 (Compiled 32bit scripts not working in system32 path on 64bit OS) updated by Emiel Wieldraaijer
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 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. 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.
Note: See TracTimeline for information about the timeline view.