Timeline
Aug 22, 2012:
- 4:32 PM Ticket #2252 (_GUICtrlListView_DeleteAllItems Bug) updated by
- Thnx Melba233 http://www.autoitscript.com/trac/autoit/ticket/1639
- 4:12 AM Ticket #2247 (Documentation needs change for @Desktop macros) updated by
- Err I tried. It became a bit long the way you wrote it so shortened and added the note to the other two.
- 3:24 AM Ticket #2240 (Strange behavior of TimerDiff) updated by
- This ticket is referenced in revision: [7182] Arggg. No it isn't. Wrong number. Ignore this.
Aug 21, 2012:
- 2:44 PM Ticket #2252 (_GUICtrlListView_DeleteAllItems Bug) created by
- The current implementation of _GUICtrlListView_DeleteAllItems …
- 10:49 AM Ticket #2250 (Add DirMove() to the "Related:" list for DirCopy() in the helpfile.) closed by
- Completed: Added by revision [7179] in version: 3.3.9.5
- 5:17 AM Ticket #2251 (variables in FileInstall's "source") updated by
- Replying to anonymous: > Hi Valik > > Sorry that I've offended you, but I really only wanted some support, and I don't believe I'm one of the idiots. Lolwut? Offend me? It's cute that you think you're capable of that. Hint: You aren't. You're not helping the "I'm not an idiot" case, though, when you want support on the issue tracker. It's kind of one of the guidelines that the issue tracker is not for support. > My wish is not to let the enduser select a file using FileOpenDialog(), but that I should be able to use a variable like e.g. I'm perfectly aware of what you want. That does not change anything, however. The compiler is not an interpreter. It cannot evaluate your simple statement any more than it can evaluate my complex statement. So what you really want is for FileInstall() to have different syntax entirely so that compile-time statements can be expanded without abusing the variable mechanism since that is entirely inappropriate. It almost sounds like I've thought about this, doesn't it?
Aug 20, 2012:
- 4:42 PM Ticket #2251 (variables in FileInstall's "source") updated by
- Replying to anonymous: > Hi Valik > > Sorry that I've offended you, but I really only wanted some support, and I don't believe I'm one of the idiots. > > My wish is not to let the enduser select a file using FileOpenDialog(), but that I should be able to use a variable like e.g. > > {{{ > $sFile = @ScriptDir & "\MyTest.exe" > FileInstall($sFile,"C:\Somewhere",1) > }}} > > But as you already have told, this is NOT possible according to [www.autoitscript.com/trac/autoit/wiki/AutoItNotOnToDoList] > > So I am aware, that this issue is 100% totally rejected and closed. > > Have a nice day ;O) > > Sincerely > > J. Malmgren > > IT-Programmer > Denmark > [www.tryware.dk]
- 4:41 PM Ticket #2251 (variables in FileInstall's "source") updated by
- Hi Valik Sorry that I've offended you, but I really only wanted some support, and I don't believe I'm one of the idiots. My wish is not to let the enduser select a file using FileOpenDialog(), but that I should be able to use a variable like e.g. […] But as you already have told, this is NOT possible according to [www.autoitscript.com/trac/autoit/wiki/AutoItNotOnToDoList] So I am aware, that this issue is 100% totally rejected and closed. Have a nice day ;O) Sincerely J. Malmgren IT-Programmer Denmark [www.tryware.dk]
Aug 19, 2012:
- 9:37 PM Ticket #2208 (ControlGetText not working on calculator) closed by
- Rejected: It would only confuse users more. My opinion at this point is that ControlGetText should not return this text as it can be anything and not necessarily what's displayed on control.
- 9:30 PM Ticket #1788 (_GUICtrlRichEdit_GetMargins and _GUICtrlRichEdit_SetMargins) closed by
- Rejected: Atually I'm bored most of the time.
- 5:11 AM Ticket #2251 (variables in FileInstall's "source") updated by
- What FileInstall() issue? The only issue with FileInstall() are the idiots who think the compiler can somehow resolve variables that aren't going to receive input until runtime. If you bothered to comprehend (the most important part of reading) all of those tickets you linked to then you would see that yes, while I did allude to a FileInstall() rewrite that never materialized, I also explicitly stated that variables as source parameters would not be implemented. Here, I'll make this easy. If you can tell me what file the compiler should include in the resulting binary for the following example script I'll implement the feature immediately. […]
Aug 18, 2012:
- 11:36 PM Ticket #2251 (variables in FileInstall's "source") updated by
- Replying to Valik: > You're not very smart. So many examples of that. Please go away. Hi Valik I actually did a lot search of the FileInstall issue, and couldn't find any solution, but only a lot of promises from you 4 years ago that it's about to be resolved according to among other #47, #220 and #768. So I decided to raise a feature request about it. I'm not satisfied with the way you answer me, because I think that you should have told me, that I forgot to read [www.autoitscript.com/trac/autoit/wiki/AutoItNotOnToDoList] before raising new feature request, instead of using the "language" you did. BTW: Please understand that I'm a very satisfied user of AutoIt for many many years Sincerely J. Malmgren IT-Programmer Denmark [www.tryware.dk]
- 5:02 PM Ticket #2251 (variables in FileInstall's "source") closed by
- Rejected: You're not very smart. So many examples of that. Please go away.
- 11:00 AM Ticket #2251 (variables in FileInstall's "source") updated by
-
Version changed
Automatic ticket cleanup. - 10:01 AM Ticket #2251 (variables in FileInstall's "source") created by
- As far as I can see in issue #768, it should be possible to use …
- 6:02 AM Ticket #2249 (RegRead(): Unexpected @extended result - possible bug) updated by
- Err, @extended is documented for successful calls. Notice that it is not documented for failures.
Aug 17, 2012:
- 9:50 PM Ticket #2249 (RegRead(): Unexpected @extended result - possible bug) updated by
- Thanks for the reply ... Not sure you are seeing what i am seeing but Your code and the minimal code posted return the same thing (Regardless of HKCU or HKLM) Yes, i did check the @error value for both which was also the same and expected ... -1 You're right, I should have included @error in the posted code. @error -1 worked for me in my working script to prevent trouble as i was only using RegRead to identify the default value type of a particular key and whether i could work with it or not. Constants.au3 defines Global Const $REG_NONE = 0 Microsoft Defines REG_NONE as "No defined value type" http://msdn.microsoft.com/en-us/library/windows/desktop/ms724884%28v=vs.85%29.aspx RegRead is erroring out with -1 (unable to open requested value) RegRead Help File says: @EXTENDED is set to the type of the value RegRead is returning @error -1, @extended 2 (Global Const $REG_EXPAND_SZ = 2) Dont see how the @extended return is appropriate under these conditions. Unless: You look at it like ... AutoIt 'said' it would be wrong (@error -1) so i guess it can put anything it wants into @extended, we were warned. Shouldn't it return something more appropriate like 0 = $REG_NONE ? Yes / No ? ... I Have nothing more to add to this so this closes it for me.
- 9:00 PM Ticket #2250 (Add DirMove() to the "Related:" list for DirCopy() in the helpfile.) updated by
-
Version changed
Automatic ticket cleanup. - 8:43 PM Ticket #2250 (Add DirMove() to the "Related:" list for DirCopy() in the helpfile.) created by
- This page intentionally left blank.
- 5:05 PM Ticket #2249 (RegRead(): Unexpected @extended result - possible bug) closed by
- No Bug: Hint: Your code sucks. Here's some real code. […] Notice the following: * I don't write to HKLM since, you know, you shouldn't write to HKLM unless you want the write redirected on Vista or later. * I take the time to clean up the registry so the mess isn't left behind. * Check the value of @error since, you know, it's kind of important SINCE AN ERROR OCCURRED. No bug, code is working as intended.
Aug 16, 2012:
- 11:29 PM Ticket #2249 (RegRead(): Unexpected @extended result - possible bug) created by
- ; RegRead(): Unexpected @extended return for REG_TYPE when ; …
- 9:01 PM Ticket #2247 (Documentation needs change for @Desktop macros) updated by
- Yes, I can confirm that. It's the same thing, the info is for primary monitor. Somebody with better English do it. ...Anonymous my ass.
- 6:37 PM Ticket #2248 (VarGetName() & @FunctionName) closed by
- Rejected: General guideline #4. If you are asking a question you are in the wrong place.
- 12:42 PM Ticket #2248 (VarGetName() & @FunctionName) created by
- This has been requested before in #609. This was four years ago, …
Aug 14, 2012:
- 11:42 PM Ticket #2247 (Documentation needs change for @Desktop macros) updated by
- The bit depth (@DesktopDepth) and refresh rate (@DesktopRefresh) are also per screen. I tested it, and they returned the primary screen for me. Could you please verify their workings and document that too?
- 7:32 PM Ticket #2247 (Documentation needs change for @Desktop macros) closed by
- Fixed: Fixed by revision [7171] in version: 3.3.9.5
Aug 13, 2012:
- 5:05 PM Ticket #2240 (Strange behavior of TimerDiff) updated by
- Addressed by revision [7170]
Aug 12, 2012:
- 4:59 AM Ticket #2247 (Documentation needs change for @Desktop macros) created by
- The macro reference for @DesktopWidth and @DesktopHeight creates …
Aug 11, 2012:
- 3:17 AM Ticket #1788 (_GUICtrlRichEdit_GetMargins and _GUICtrlRichEdit_SetMargins) updated by
- I personally no longer have any interest in this enhancement. There are tons of inaccessable RTF tags. You guys already have enough to do.
Aug 10, 2012:
- 9:03 PM Ticket #2089 (_IEFormSubmit gives WEnd^ ERROR) updated by
- When I use the IE.au3 posted here the WEnd error is gone, bust now I get: --> IE.au3 V2.4-0 Warning from function _IEFormGetObjByName, $_IEStatus_NoMatch --> IE.au3 V2.4-0 Error from function _IEFormElementGetObjByName, $_IEStatus_InvalidDataType --> IE.au3 V2.4-0 Error from function _IEFormElementSetValue, $_IEStatus_InvalidDataType --> IE.au3 V2.4-0 Error from function _IEFormElementGetObjByName, $_IEStatus_InvalidDataType --> IE.au3 V2.4-0 Error from function _IEFormElementSetValue, $_IEStatus_InvalidDataType --> IE.au3 V2.4-0 Error from function _IEFormSubmit, $_IEStatus_InvalidDataType So this seems not to be the solution.
- 6:28 PM Ticket #2246 (Excel.au3: Some more constants) updated by
-
Component changed
- 5:50 PM Ticket #2245 (Microsoft Access UDF) updated by
- This UDF can work without office. On any OS Win2K to 7
Aug 9, 2012:
- 9:19 PM Ticket #2246 (Excel.au3: Some more constants) created by
- The following constants are missing from excel.au3: […] You …
- 6:57 PM Ticket #2245 (Microsoft Access UDF) closed by
- Rejected: Thanks but no.
- 12:32 PM Ticket #2242 (_FileWriteFromArray is incapable of writing only the zeroth element) updated by
- If you think or feel you need patronizer then maybe you shouldn't write that function. I'm just saying. <-who says that? lol
- 9:54 AM Ticket #2245 (Microsoft Access UDF) updated by
- Replying to TicketCleanup: > Automatic ticket cleanup. work on any version. also good for 3.3.8.1 or better.
- 9:00 AM Ticket #2245 (Microsoft Access UDF) updated by
-
Version changed
Automatic ticket cleanup. - 8:44 AM Ticket #2245 (Microsoft Access UDF) created by
- - This UDF will be connected to MDB file - Can read/write/query data. …
Aug 8, 2012:
- 9:36 PM Ticket #2242 (_FileWriteFromArray is incapable of writing only the zeroth element) updated by
- I also came up with this as an alternative line […] This change would allow the use of -1 in the $i_UBound parameter to indicate the default parameter.
- 9:33 PM Ticket #2242 (_FileWriteFromArray is incapable of writing only the zeroth element) updated by
- Here's what I came up with for a fix. I've also added in another error code because the original function would take a start index that is greater than the end index as a valid input, it would convert it to 0 in that case. I changed it to an error condition. […]
- 9:00 AM Ticket #1700 (Synchronous ObjEvent) updated by
-
Milestone changed
Automatic ticket cleanup. - 8:04 AM Ticket #1700 (Synchronous ObjEvent) closed by
- Completed: Addressed by revisions [7158], [7163] and added by rev [7164].
Aug 7, 2012:
- 8:57 PM Ticket #2219 (_ExcelReadSheetToArray() fix and upgrade) updated by
- Thumbs up! I hit this bug, and am relieved by the much increased speed of your code. ...chris
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 …
Note:
See TracTimeline
for information about the timeline view.
