Timeline
Aug 5, 2012:
- 4:43 PM Ticket #2244 (_ExcelNumberFormat: bug in Example 2) updated by
-
Version changed
- 4:00 AM Ticket #2244 (_ExcelNumberFormat: bug in Example 2) updated by
-
Version changed
Automatic ticket cleanup. - 3:47 AM Ticket #2244 (_ExcelNumberFormat: bug in Example 2) created by
- […] should be […]
Aug 4, 2012:
- 3:04 AM Ticket #2242 (_FileWriteFromArray is incapable of writing only the zeroth element) updated by
- This is really stupid. I expected this function to be written by some stupid dumbass... but nope, it was written by somebody who should have known better. Anyway, this function is dumb and broken. Please re-write it correctly. All I ask is that you do not modify the function signature. Chances are people who are writing the entire array aren't even specifying 0 explicitly so if it's changed to Default it will only affect a very small number of people who are writing the entire array using a non-default delimiter. Or idiots who wrote bad code but I don't care about them.
- 2:59 AM Ticket #2197 (#RequireAdmin creates a critical error, if the user doesn't start it ...) updated by
- The more I see this bug report the more annoyed I get at the reporter. What a shitty bug report, whether it turns out to be real or not.
- 1:31 AM Ticket #2197 (#RequireAdmin creates a critical error, if the user doesn't start it ...) updated by
- From the second block of code, I'd guess Windows XP (NT 5.1)…
Aug 3, 2012:
- 8:49 PM Ticket #2242 (_FileWriteFromArray is incapable of writing only the zeroth element) updated by
- I'd have to agree on that as well, if this had been written correctly in the first place, 0 would never have meant the whole array because AutoIt arrays are 0 based, and not 1 based. It should probably be rewritten to use the Default keyword in the $i_Ubound parameter, but at least the way it's written above would allow you to write out only the first element of the array.
- 5:34 PM Ticket #2243 (#Include <%Environment variable path%\Script.au3>) closed by
- Rejected: Yeah, that's an exceptionally stupid idea. It outright guarantees scripts must be edited to adjust paths if you ever try to use the script on a different machine that doesn't have the environment variable set. Then there's the FUD in your post. It's not tedious to update the registry unless you have to do it often which you should not have to do. Finally... write your own simple GUI? I did and I even posted it on the forum although I can't find it now. It's like 30 minutes work and ~100 lines of code to present a UI that lists the current directories and provides add and remove buttons.
- 5:13 PM Ticket #2243 (#Include <%Environment variable path%\Script.au3>) created by
- That would be awesome if AutoIt could include files that have an …
Aug 2, 2012:
- 8:42 PM Ticket #2242 (_FileWriteFromArray is incapable of writing only the zeroth element) updated by
- That's why Default keyword should be used instead of magic numbers/strings.
- 3:51 PM Ticket #2242 (_FileWriteFromArray is incapable of writing only the zeroth element) created by
- In the File.au3 UDF, the function _FileWriteFromArray can't be used to …
Aug 1, 2012:
- 8:27 AM Ticket #2240 (Strange behavior of TimerDiff) updated by
- Ok, thanks for the infos.
Jul 31, 2012:
- 5:28 PM Ticket #2240 (Strange behavior of TimerDiff) updated by
- Replying to anonymous: > So maybe it makes sense to add my function to the timers udf to help others which run into similar problem? That is not and would never be a good reason to add a function to the language. Things should be useful for the majority, not the minority. It's all a moot point, anyway. The function _Date_Time_GetTickCount() already exists and does the same thing although it uses GetTickCount() instead of timeGetTime(). Since you aren't using timeBeginPeriod() and timeEndPeriod() your resolution isn't really any more or less accurate than GetTickCount() unless some other program has requested a high resolution. Further, since timeBeginPeriod() changes the entire system it should be left up to the application (read: user) to call it, not hide it away behind some API.
- 5:19 PM Ticket #2241 (AUTOIT3 cannot automate installing softwares while screen is locked) closed by
- No Bug: In other shocking news, user is too stupid to read ticket guidelines and ask questions on the forum where they belong. Very obviously no bug.
- 9:53 AM Ticket #2241 (AUTOIT3 cannot automate installing softwares while screen is locked) created by
- AUTOIT3 is a great software. By automating it saves us a lot of time. …
- 8:37 AM Ticket #2240 (Strange behavior of TimerDiff) updated by
- So maybe it makes sense to add my function to the timers udf to help others which run into similar problem?
- 5:08 AM Ticket #2171 (Inconsistent delay for TCPTimeout option) updated by
- It wasn't me and it wasn't Jon which pretty much explains it all, really.
Jul 30, 2012:
- 10:28 PM Ticket #2171 (Inconsistent delay for TCPTimeout option) updated by
- AutoIt's implementation is stupid because it miscalculates delay from user's input. Underlying API, strictly speaking, allows microsecond precision. API's internal timer is on top of that very precise. Miscalculation scheme is incredibly strange (stupid maybe even) that it actually made me think it was done on purpose. I even checked logs to see who wrote that part of the code, but it's too old and not logged therefore.
- 3:49 PM Ticket #2171 (Inconsistent delay for TCPTimeout option) updated by
- It's not inconsistent. For whatever reason the input is in milliseconds but the actual time waited is in seconds. If the underlying API only accepts seconds then AutoIt's design is stupid and shouldn't accept milliseconds when they are going to be converted to seconds internally (with associated precision loss due to storage in an integer). If the underlying API does allow milliseconds then AutoIt's implementation is stupid for converting to seconds. To test that this is NOT actually inconsistent but rather based on a conversion to seconds simply enter a time like 1750 and you'll see that it waits for 1 second.
- 3:40 PM Ticket #2240 (Strange behavior of TimerDiff) updated by
- Why would I talk about QueryPerformanceCounter() and QueryPerformanceFrequency() in comment 2 if we were using something else?
- 9:44 AM Ticket #2240 (Strange behavior of TimerDiff) updated by
- Replying to trancexx: Just for my information, which functions are behind TimerInit and TimerDiff()?
- 8:21 AM Ticket #2171 (Inconsistent delay for TCPTimeout option) updated by
-
Summary changed
- 8:19 AM Ticket #2171 (Inconsistent delay for TCPTimeout option) updated by
- The code is meant to produce time delay. The fact that it does it inconsistently is a bug. For example, TCPTimeout 327 should sleep for 327 ms.
Jul 29, 2012:
- 10:10 PM Ticket #2234 (_TempFile Infinite loop bug) updated by
- You're right, it could happen. Because you wrote shit code and limited your possible unique file names to 99 (or 100 if 00 is used) and didn't bother to clean those files up when they are no longer in use. That isn't the fault of the function, that's the fault of you writing bad code.
- 5:33 PM Ticket #2234 (_TempFile Infinite loop bug) updated by
- Yes, very few times, but it happened for me, and it was very hard (for me) to find that the bug was from this function. For example if you call it like this […] It could happen Anyway, thanks for reading me.
Jul 28, 2012:
- 8:29 AM Ticket #2240 (Strange behavior of TimerDiff) updated by
- My intention wasn't to fix anything. The issue can't be fixed. This is not about small error in calculation or maybe TimerDiff() inacuracy of some sort. This is about complete failure. The user has hardware (specific type of processor) for which our function doesn't work correctly. It's not about software. Anyway, situation about the bug is very specific. Our function description should include disclamer. Won't fix would have been my resolution too. The main purpose of this ticket is future referencing.
Jul 27, 2012:
- 5:35 PM Ticket #2240 (Strange behavior of TimerDiff) updated by
- Why do people think they have to take screenshots of error messages? 1. A message box's text can be copied by Ctrl+c. 2. Output to the console, display console output. Duh. As for the sleep inaccuracy, notice I also added "AutoIt overhead". Finally, you didn't provide a link to the forum thread and I'm certainly not going to spend my time searching for it. If trancexx wants to fix this in a way that doesn't change the behavior she can but I think that it is pointless waste of time. The function works for most people. For the rest most people won't even care about being off for a few hundred milliseconds. Of that super small subset that do care they can use a different method as you have done.
- 8:53 AM Ticket #2240 (Strange behavior of TimerDiff) updated by
- Replying to Valik: For me its fine since my probem is solved. I have been advised to make a bug report by trancexx. In addition I didn't want to overload the ticket with additional screen pictures which are allready in the forum thread, anyhow as you could see in the listing, with a sleep of 5000 there is a result between 200 and 500 which could not be the well known sleep accuracy since it is much smaller. > What do you want us to do about it? Change the behavior because a limited number of systems have issue with the function? The function works fine for most people because most people have a system that does sensible things with QueryPerformanceCounter() and QueryPerformanceFrequency(). > > In addition, since you didn't bother to actually provide any output from your scripts, how do I know it's not just the well known sleep inaccuracy + AutoIt overhead? I don't. > > I'm closing this as won't fix. As I said, most people's system give consistent and sensible results so changing the behavior of the function to cater to the minority makes little sense.
Jul 26, 2012:
- 6:07 PM Ticket #2240 (Strange behavior of TimerDiff) closed by
- Wont Fix: What do you want us to do about it? Change the behavior because a limited number of systems have issue with the function? The function works fine for most people because most people have a system that does sensible things with QueryPerformanceCounter() and QueryPerformanceFrequency(). In addition, since you didn't bother to actually provide any output from your scripts, how do I know it's not just the well known sleep inaccuracy + AutoIt overhead? I don't. I'm closing this as won't fix. As I said, most people's system give consistent and sensible results so changing the behavior of the function to cater to the minority makes little sense.
- 5:00 PM Ticket #2238 (Syntax check warning on using variable inside declare state) updated by
- You assume that I will get the same results. I may not get the same results so without you explicitly providing the error message we may end up talking about two different things.
- 4:59 PM Ticket #2237 (SetError/Extended returns 1 if return value is omitted) updated by
- It means don't fucking use the return value because it's not defined.
- 1:15 PM Ticket #2240 (Strange behavior of TimerDiff) updated by
- The exists a discussion in the forum unter the entry "Strange behavior of TimerDiff".
- 1:12 PM Ticket #2240 (Strange behavior of TimerDiff) created by
- On some PC's (Intel Core2 Duo, E8400 3GHz) i have got strange results …
- 12:39 PM Ticket #2239 (if ObjEvent("AutoIt.Error") with only one arg will crash) closed by
- No Bug: Many things don't work on that version of AutoIt. Intentionally.
- 12:31 PM Ticket #2238 (Syntax check warning on using variable inside declare state) updated by
- I will ask question then. Do you know difference between warning and error? Anyway, this is legacy thing, right or wrong. Using "MustDeclareVars" option that script wouldn't run.
- 11:38 AM Ticket #2237 (SetError/Extended returns 1 if return value is omitted) updated by
- Replying to Valik: > It DOES NOT mean 0 But it also does not mean 1, right? :)
- 11:36 AM Ticket #2238 (Syntax check warning on using variable inside declare state) updated by
- 1. I thought the warning is obvious: […] 2. I don't asking a question, it was rhetorical. 3. The code is probably stupid, but AutoIt interpreter handle it properly. Just try to compile the script (ignore the warning) and run it.
- 11:22 AM Ticket #2233 (TraySetOnEvent does not set $TRAY_EVENT_PRIMARYDOWN properly) updated by
- Then why we need this event, i think it should be removed. Or replace it with $TRAY_EVENT_DRAGBEGIN/END events.
- 4:10 AM Ticket #2239 (if ObjEvent("AutoIt.Error") with only one arg will crash) created by
- […] this work on 3.3.9.4 not work on …
Jul 25, 2012:
- 10:37 PM Ticket #1681 (Automate capture and apply partitioning in GimageX to address EFI ...) updated by
-
Component changed
- 9:20 PM Ticket #2233 (TraySetOnEvent does not set $TRAY_EVENT_PRIMARYDOWN properly) closed by
- No Bug: It's windows thing. WM_LBUTTONDOWN message is send back to us after explorer confirms you are not trying to initiate drag operation. That happens right before you release the button if no mouse move happened in the meantime. Therefore no bug.
- 5:43 PM Ticket #2238 (Syntax check warning on using variable inside declare state) closed by
- No Bug: 1. It would have been helpful if you had provided the warning message. 2. See the part in the new ticket guidelines where it says "If you are asking a question you are at the wrong place"? You're at the wrong place. 3. That is some incredibly stupid code.
- 5:39 PM Ticket #2237 (SetError/Extended returns 1 if return value is omitted) closed by
- No Bug: I don't think you understand what "none" means. It DOES NOT mean 0, otherwise it would have stated as much.
- 5:36 PM Ticket #2236 (GUI Automation support for 3rd party Grid control) closed by
- Rejected: That's nice.
- 2:30 PM Ticket #2235 (if process not exist,ProcessGetStats will not return 0.) updated by
- sorry.i was wrong.
- 1:50 PM Ticket #2238 (Syntax check warning on using variable inside declare state) created by
- I got warning with this example: […] But if i press «Continue …
- 1:43 PM Ticket #2237 (SetError/Extended returns 1 if return value is omitted) created by
- Help file states: […] But it's not true, SetError/SetExtended …
- 1:00 PM Ticket #2236 (GUI Automation support for 3rd party Grid control) updated by
-
Version changed
Automatic ticket cleanup. - 12:35 PM Ticket #2236 (GUI Automation support for 3rd party Grid control) created by
- Hi, I need to automate a grid control which is developed by a third …
Jul 24, 2012:
- 6:20 PM Ticket #2234 (_TempFile Infinite loop bug) closed by
- No Bug: You mean sometimes as once in 100 hundred billion trillion times or never?
- 4:33 PM Ticket #2235 (if process not exist,ProcessGetStats will not return 0.) closed by
- Fixed: Fixed by revision [7132] in version: 3.3.9.5
- 4:10 PM Ticket #2235 (if process not exist,ProcessGetStats will not return 0.) updated by
- You do realize we didn't write AutoIt in assembly right? Why the fuck would I care about seeing some disassembly when I have the source code? I looked at the source and the error is stupid obvious. More importantly, though, why shouldn't I permanently block you from this site? Disassembling and attempting to tell me how to fix the code based on that disassembly dump is reverse engineering. The last time I checked we had a very specific clause in the AutoIt license agreement about reverse engineering.
- 3:52 AM Ticket #2235 (if process not exist,ProcessGetStats will not return 0.) created by
- […] if process not exist,ProcessGetStats will not return 0.
Jul 23, 2012:
- 5:33 PM Ticket #2234 (_TempFile Infinite loop bug) created by
- Hi! Sometimes, _TempFile enters in an infinite loop, because there is …
Jul 20, 2012:
- 4:10 PM Ticket #2233 (TraySetOnEvent does not set $TRAY_EVENT_PRIMARYDOWN properly) created by
- Check this example: […] Both MsgBoxes shown after we release …
Jul 17, 2012:
- 8:41 PM Ticket #2232 (FileSetAttrib help file example - hardcrash) closed by
- Works For Me: Your report misses all the info that you should have provided. Even though help file examples for this function are catastrophic they don't error out in that manner for me.
- 8:16 PM Ticket #2232 (FileSetAttrib help file example - hardcrash) created by
- The help file example of FileSetAttrib with wildcards causes …
- 6:41 AM Ticket #2227 (GUICtrlCreateEdit doesn't have full Unicode support) updated by
- At least it must be removed from the doc/Udf constants
Jul 16, 2012:
- 2:23 PM Ticket #2192 (New API...au3 include files conflict) closed by
- Fixed: Fixed by revision [7128] in version: 3.3.9.5
- 9:53 AM Ticket #1571 (StringSplit - Add CaseSense parameter) closed by
- Rejected: Case insensitive split would result in 100 bug reports by users using languages other than English. AutoIt string is not limited to ASCII character set.
- 9:37 AM Ticket #1674 (DirCopy()/DirMove() does not preserve the attributes of a folder) closed by
- Rejected
- 9:30 AM Ticket #263 (Drop PluginOpen()/PluginClose() in favor of an #import statement) closed by
- Rejected: Plugin feature will not be developed further.
Jul 12, 2012:
- 12:42 PM Ticket #2149 (_StringBetween does not accept NULL-chars in the boundary strings) updated by
- Please provide an example that doesn't work for you.
- 12:16 PM Ticket #2223 (Minor documentation correction for _WordErrorHandlerRegister) closed by
- Fixed: Fixed by revision [7124] in version: 3.3.9.5
- 1:39 AM Ticket #2231 (ControlSend case of text inconsistent) closed by
- No Bug: You provided a script to reproduce the issue about as useful as the scripts 2 years ago. In other words, this is pointless. We can't reproduce it and the code looks fine on our end.
- 12:22 AM Ticket #2219 (_ExcelReadSheetToArray() fix and upgrade) updated by
- This is likely more efficient than the If/Else statement added to the last version to handle $iColShift on single-cell sheets: […]
- 12:11 AM Ticket #2219 (_ExcelReadSheetToArray() fix and upgrade) updated by
- I noticed I was not handling the $iColShift parameter when a single-cell sheet was the target. I've corrected that. I also found a post by Footswitch proposing the use of "range" instead of "cell" to improve speed. The post is older than the Golfinhu post, so I now credited them both in the comments. Updated version: […]
Jul 11, 2012:
- 7:32 PM Ticket #2231 (ControlSend case of text inconsistent) created by
- This was reported previously, but it was closed 2 years ago as "no …
Jul 10, 2012:
- 6:00 PM Ticket #2230 (MsgBox - Add Location Parameters) updated by
-
Version changed
Automatic ticket cleanup. - 3:56 PM Ticket #2229 (Bug in Obfuscator.exe v1.0.30.1) closed by
- Wont Fix: This is not the correct place to report issues with SciTE4AutoIt or it's tools.
- 3:55 PM Ticket #2230 (MsgBox - Add Location Parameters) closed by
- Rejected: Message boxes are a standard Windows feature. Talk to Microsoft. Better yet spend about two seconds thinking about how you could achieve this on your own and you'll see you can do it already. I hear AutoIt is a good automation language for manipulating windows.
- 3:20 PM Ticket #2230 (MsgBox - Add Location Parameters) created by
- I very often want a MsgBox that is NOT centered on the screen. How …
Jul 9, 2012:
- 9:20 PM Ticket #2229 (Bug in Obfuscator.exe v1.0.30.1) updated by
- I mean […] will be ignored.
- 9:12 PM Ticket #2229 (Bug in Obfuscator.exe v1.0.30.1) created by
- […] I don't know who will maintain SciTE and its components in …
Note:
See TracTimeline
for information about the timeline view.
