Timeline
Jan 6, 2010:
- 8:41 PM Ticket #1311 (MouseGetCursor() - identify also standard hand cursor (IDC_HAND)) closed by
- Completed: Added by revision [5549] in version: 3.3.3.2
- 7:33 PM Ticket #1262 (Add SMTP AUTH to _INetSmtpMail() in inet.au3) updated by
-
Owner, Status changed
- 7:32 PM Ticket #1262 (Add SMTP AUTH to _INetSmtpMail() in inet.au3) updated by
- I don't know which version of _InetSmtpMail was used to add the capability but as I cannot test anymore, I will be glad to have an update base on current Release 3.3.2.0 Thanks
- 6:07 PM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) reopened by
- If I wanted this ticket closed I would have closed this ticket.
- 6:00 PM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) updated by
-
Milestone changed
Automatic ticket cleanup. - 5:07 PM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) closed by
- Fixed
- 5:03 PM Ticket #1396 (DllCallbackGetPtr crashes on invalid handle) created by
- Not much to say. DllCallbackGetPtr() produces an access violation on …
- 4:56 PM Ticket #1353 (_FileWriteToLine() excessively strict on input text type) updated by
- Perhaps I am wrong but as this UDF was design to receive String it is the use responsability to pass string. So for me there is no bug.
- 4:28 PM Ticket #1352 (StringSplit hard crash on binary data) updated by
- Any more info as It cannot be reproduced ;)
- 11:16 AM Ticket #1395 (DLLCallbacks on Exit) updated by
- Oh, sorry, Autoit IS calling the OnExitFuncs when "Array out of bounds" is shown, so the only thing remaining is exit without freeing the object. i will attach the shortest Object i could think of
- 10:50 AM Ticket #1360 (for what are these files) closed by
- Fixed: Fixed by revision [5536] in version: 3.3.3.2
- 10:48 AM Ticket #1360 (for what are these files) updated by
- index.htm is supposed to be use on the help access thru the Web. Not sure Jon is taking care of it. For the other issues will be fixed next beta.
- 7:15 AM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) updated by
- This ticket is referenced in revision: [5528]
- 6:53 AM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) updated by
- This ticket is referenced in revision: [5525]
- 6:48 AM Ticket #1392 (OnAutoItExitRegister is causing AutoIT to crash) updated by
-
Severity changed
- 6:47 AM Ticket #1393 (Script crashes with error reported in EventLog.au3 at line 475) closed by
- Fixed: Fixed by revision [5524] in version: 3.3.3.2
- 6:32 AM Ticket #1384 (404 Not Found error when clicking links for explanations of functions) updated by
-
Owner, Status changed
Jan 5, 2010:
- 11:19 PM Ticket #1395 (DLLCallbacks on Exit) updated by
- Do you have an example that you'd like to see working without crashes (simple, please, and not related to #1319)? I need to see exactly what you're thinking to tell if it even makes sense from an object-lifetime standpoint. Also, I don't think that AutoIt should crash so I would like to fix that, at least, even if your request doesn't make sense from a lifetime standpoint.
- 10:16 PM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) closed by
- Fixed: Fixed by revision [5523] in version: 3.3.3.2
- 10:00 PM Ticket #1395 (DLLCallbacks on Exit) updated by
-
Version changed
Automatic ticket cleanup. - 9:32 PM Ticket #1395 (DLLCallbacks on Exit) created by
- I wish it would be possible to have DLLCllbacks persist longer in the …
- 8:00 PM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) updated by
-
Milestone changed
Automatic ticket cleanup. - 6:21 PM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) reopened by
- Fixing one page and ignoring the dozen others that are also broken doesn't mean the ticket is closed.
- 6:19 PM Ticket #1384 (404 Not Found error when clicking links for explanations of functions) reopened by
- If a bug is not fully fixed, don't close the bug report.
- 6:18 PM Ticket #1394 (Comodo Internet Security reports dangerous program) closed by
- No Bug: I can tell you to use the forum if you want to ask questions or need support.
- 5:01 PM Ticket #1394 (Comodo Internet Security reports dangerous program) created by
- CIS are labelling Scite program TheHook.dll as a dangerous program. I …
- 4:39 PM Ticket #1393 (Script crashes with error reported in EventLog.au3 at line 475) created by
- My Usage: Script uses EventLog.au3 to access remote event logs. The …
- 2:00 PM Ticket #1361 (_SetTime() and _SetDate() crash when accessing non-array) updated by
-
Milestone changed
Automatic ticket cleanup. - 1:25 PM Ticket #1361 (_SetTime() and _SetDate() crash when accessing non-array) closed by
- Fixed: Solved by #1378
- 1:24 PM Ticket #1378 (Wrong error handling in _Date_Time_SetLocalTime) closed by
- Fixed: Fixed by revision [5520] in version: 3.3.3.2
- 12:14 PM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) closed by
- Fixed: Fixed by revision [5519] in version: 3.3.3.2
- 12:07 PM Ticket #1384 (404 Not Found error when clicking links for explanations of functions) updated by
- The .chm link has been fix. Not sure who can fix the Web ones
- 12:05 PM Ticket #1384 (404 Not Found error when clicking links for explanations of functions) closed by
- Fixed: Fixed by revision [5518] in version: 3.3.3.2
- 7:50 AM Ticket #1392 (OnAutoItExitRegister is causing AutoIT to crash) updated by
- Sorry. The example from the help file is what was used to produce the bug. >Exit code: -1073741819 Time: 3.949 AutoIt:3.3.3.1 (Os:WIN_7/X86 Language:0409 Keyboard:00000409 Cpu:X64)
- 6:40 AM Ticket #1392 (OnAutoItExitRegister is causing AutoIT to crash) updated by
- This bug report is just plain unacceptable. The title DOES NOT say it all and if you had bothered to read WikiStart you'd know that.
- 6:02 AM Ticket #1392 (OnAutoItExitRegister is causing AutoIT to crash) created by
- The title says it all..
- 12:31 AM Ticket #1391 (AU3Info Toolsbar page returns info allways on instance 1 instead of ...) created by
- The AutoIT V3 info added the feature as described in ticket #140. …
Jan 4, 2010:
- 11:11 PM Milestone 3.3.3.1 completed
- 10:57 PM Ticket #1341 (Win7 x64 - Cannot send any messages to dialog controls) updated by
- Certain functions won't work if you try and use x64 AutoIt with an x86 process or vice versa. Is this what is happening here? You need to use the same arch version of Autoit to control the process. We probably need to document which functions are affected and if there is an feasible workaround (last time I remember checking I think I'd decided there wasn't...)
- 10:51 PM Ticket #682 (Remove 64K line limit for FileReadLine()) closed by
- Completed: Added by revision [5514] in version: 3.3.3.1
- 10:22 PM Ticket #1387 (_IECreate() - bug with 3.3.3.0 beta) updated by
- There was no need to create a new ticket to state exactly what you've stated here already. Subsequently I've deleted the other ticket. I still cannot reproduce the issue. SciTE has nothing to do with this.
- 9:57 PM Ticket #1389 (Multiple _IEAttach Use Fails) closed by
- Fixed: Fixed by revision [5509] in version: 3.3.3.1
- 8:59 PM Ticket #1387 (_IECreate() - bug with 3.3.3.0 beta) updated by
- the error exists only then when 3.3.3.0 beta is instaled and scite is instaled only from autoit setup and no from http://www.autoitscript.com/autoit3/scite/downloads.shtml
- 8:25 PM Ticket #1387 (_IECreate() - bug with 3.3.3.0 beta) closed by
- Works For Me: Closing as works for me since I can't reproduce the issue.
- 8:02 PM Ticket #1390 (ControListView causes Microsoft Management Console to crash ...) closed by
- No Bug
- 8:00 PM Ticket #1390 (ControListView causes Microsoft Management Console to crash ...) updated by
- I just noticed that I was using an outdated version of autoit. Updated to 3.3.2.0, and the problem is resolved. The ticket can be closed. Sorry for the inconvenience.
- 7:48 PM Ticket #1390 (ControListView causes Microsoft Management Console to crash ...) created by
- script: […] output from _DebugBugReportEnv() […] When the …
- 5:51 PM Ticket #1389 (Multiple _IEAttach Use Fails) created by
- After upgrading from 3.3.0.0 to 3.3.2.0, multiple calls to _IEAttach …
- 4:04 PM Ticket #1388 (GUIRegisterMsg() return value) updated by
- > The @extended macro can only return numeric values. Upsa, forgot that, sorry. > I'm closing this as rejected. At some point all our "Register" stuff should use a > stack similar to AdlibRegister(). Looking forward :)…
- 3:35 PM Ticket #1388 (GUIRegisterMsg() return value) closed by
- Rejected: The @extended macro can only return numeric values. I'm closing this as rejected. At some point all our "Register" stuff should use a stack similar to AdlibRegister().
- 2:54 PM Ticket #1219 (Fix TracTicketDelete) closed by
- Fixed: Fixed by upgrading to a newer version of the plugin.
- 2:00 PM Ticket #1388 (GUIRegisterMsg() return value) updated by
-
Version changed
Automatic ticket cleanup. - 1:56 PM Ticket #1388 (GUIRegisterMsg() return value) created by
- Hi Lads, I think I've read this already in past somewhere, but …
- 1:12 PM Ticket #1387 (_IECreate() - bug with 3.3.3.0 beta) created by
- _IECreate()displays an error with version 3.3.3.0 beta […] ERROR: …
- 1:21 AM Ticket #1386 (Union support) closed by
- Rejected: That syntax won't work. DllStructGetData() wouldn't know what to return. Thinking about it, why is this an issue? Don't you know at compile time which particular piece of data you want? For example, in your example, assume you want to use the "short" data. You calculate the size of the member to be 64-bits (the size of the largest union member which is double). Thus you would use int64. I can't imagine it being very common that you need to access more than one type of union members. I think I'm going to close this as rejected because: 1. I don't see many unions. 2. The syntax is going to be difficult to get usable in order for AutoIt to do the right thing. 3. My experience with unions has been that I needed one of the data types so in AutoIt I would just use the best size type for that data-type.
- 1:01 AM Ticket #1386 (Union support) updated by
-
Syntax is tricky. DllUnionCreate() is the obvious solution, but makes it rather useless since most unions in the wild are found in structs with other members as well.
Maybe something like this?
DllStructCreate("int;{short;float;double;}")Where everything inside the {} is treated as a union. If it could be nested then it would be perfect. It would solve any kind of data format involving unions I've seen.
Jan 3, 2010:
- 6:56 PM Ticket #1386 (Union support) updated by
- Did you have a specific syntax in mind?
- 6:00 PM Ticket #1386 (Union support) updated by
-
Version changed
Automatic ticket cleanup. - 4:53 PM Ticket #1386 (Union support) created by
- Working with unions in dllstructs is extremely annoying and tiresome …
- 4:20 PM Milestone 3.3.3.0 completed
- 8:56 AM Ticket #110 (GUICtrlCreateObj controls do not correctly track focus.) updated by
- Thank you for confirming a bug I didn't fix is still occurring…
- 6:59 AM Ticket #110 (GUICtrlCreateObj controls do not correctly track focus.) updated by
- Still happening with Version: 3.3.0.0 Production
Jan 2, 2010:
- 10:57 PM Ticket #1385 (AV scan by Comodo Internet Security) closed by
- No Bug: Inform your AV provider. The thehook.dll is indeed a dll that hooks the keyboard and mouse because that what it is needed to make a macrogenerator. Anyway, closing this ticket.
- 10:26 PM Ticket #1385 (AV scan by Comodo Internet Security) updated by
- Read this: Are my AutoIt EXEs really infected? http://www.autoitscript.com/forum/index.php?showtopic=34658
- 9:52 PM Ticket #1385 (AV scan by Comodo Internet Security) created by
- Further to my previous message...Here are some more details... In an …
- 7:17 PM Ticket #1383 (AU3Check: false warning.) updated by
- Clear. Thanks for additional doc.
- 6:31 PM Ticket #1384 (404 Not Found error when clicking links for explanations of functions) created by
- In the GUI Basic Functions sections on page …
- 4:20 PM Ticket #1383 (AU3Check: false warning.) updated by
- Au3Check makes no determination between non-Const and Const when it does its check for usage. Thus if it were to test Global variables you would get several hundred warnings for files with a lot of Global Const variables. Local variables (Const or not) can safely be tested for use because there aren't going to be hundreds of unused constants at function scope.
- 8:33 AM Ticket #1383 (AU3Check: false warning.) updated by
- nevermind. -w 5 : local var declared but not used (off)
- 8:05 AM Ticket #1383 (AU3Check: false warning.) updated by
- Ok, I think I see the logic of it. In that case I should put in a additional question mark. (?) no warning for $var1.
- 12:46 AM Ticket #1355 (Data types mixed) closed by
- Fixed: Fixed by revision [5497] in version: 3.3.3.0
- 12:37 AM Ticket #1340 (Send("{ENTER}") in IE7) closed by
- Works For Me: Closing as works for me since I can't reproduce the problem.
- 12:33 AM Ticket #1354 (sqlite function problem...) closed by
- Works For Me: Closing as works for me since the user failed to provide any useful information.
- 12:31 AM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) closed by
- Fixed: Fixed by revision [5496] in version: 3.3.3.0
- 12:25 AM Ticket #1381 (_ArraySearch subindex default doesn't match definition) closed by
- Fixed: Fixed by revision [5495] in version: 3.3.3.0
Jan 1, 2010:
- 11:14 PM Ticket #1363 (FileSetPos() error) updated by
- This ticket is referenced in revision: [5493]
- 11:10 PM Ticket #1363 (FileSetPos() error) closed by
- Fixed: Fixed by Jon and myself in 3.3.3.0 by revision [5491].
- 7:51 PM Ticket #1383 (AU3Check: false warning.) closed by
- No Bug: The warning is correct. The variable is never used and there are no side effects to either assignment statement. You can remove the variable and the code will behave exactly the same.
- 7:19 PM Ticket #1383 (AU3Check: false warning.) created by
- […]
- 2:53 AM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) updated by
- _GDIPlus_BrushGetType _GDIPlus_GraphicsGetSmoothingMode _GDIPlus_GraphicsMeasureString _GDIPlus_ImageGetFlags _GDIPlus_ImageGetHorizontalResolution _GDIPlus_ImageGetPixelFormat _GDIPlus_ImageGetRawFormat _GDIPlus_ImageGetType _GDIPlus_PenGetAlignment _GDIPlus_PenGetDashCap _GDIPlus_PenGetDashStyle _GDIPlus_PenGetEndCap
Dec 31, 2009:
- 11:55 PM Ticket #1381 (_ArraySearch subindex default doesn't match definition) updated by
- If you can't read what's in the boxes in this Issue, it's probably because I used a single line - your browser may make the scrollbar cover the text... Regardless, Here are the entries outside of the boxes Array.au3: Func _ArraySearch(Const ByRef $avArray, $vValue, $iStart = 0, $iEnd = 0, $iCase = 0, $iPartial = 0, $iForward = 1, $iSubItem = -1) Array.au3 comment block: ; Syntax.........: _ArraySearch(Const ByRef $avArray, $vValue[, $iStart = 0[, $iEnd = 0[, $iCase = 0[, $iPartial = 0[, $iForward = 1[, $iSubItem = 0]]]]]]) AutoIt 3.3.2.0 Help File: _ArraySearch(Const ByRef $avArray, $vValue [, $iStart = 0 [, $iEnd = 0 [, $iCase = 0 [, $iPartial = 0 [, $iForward = 1 [, $iSubItem = 0]]]]]])
- 6:19 PM Ticket #1382 (Windows 7 Taskbar API) closed by
- Rejected: I see nothing that suggests you can't implement this on your own.
- 6:06 PM Ticket #1365 (Windows 2000: GUICtrlCreateLabel before GUICtrlCreateCombo prevent ...) updated by
- Telling us something we know and have documented doesn't help. When you do not specify a parameter AutoIt uses an internal default. I don't know what it defaults to and I don't care to look. Its probably using your last specified height (if you specified one). In your example this last used height is too small. If no height was specified at all then it uses a different internal value which is clearly large enough. That doesn't change the fundamental problem, however, which is your code. You refuse to specify a height parameter knowing full well (being that its documented) that you have to specify an unusually large height on Windows 2000 in order for the control to appear correctly. If you try to take the lazy way out and it doesn't work, its not necessarily a bug. It just means you need to stop being lazy. The fact that its documented that the height parameter is important on Windows 2000 should be your first clue you need to explicitly control it yourself and not leave it up to chance.
- 1:01 PM Ticket #1365 (Windows 2000: GUICtrlCreateLabel before GUICtrlCreateCombo prevent ...) updated by
- And I thought help is welcome... I never forced anything! I've just pointed my finger to somthing that seems strange to me and because english is'nt my native language im not realy able to weigh one's words If i get a return where is obvious that the "problem" is not understood i'll try to explain it a 2nd time. You still dont want see what im talking about. I know about that hight parameter but that is not the point The point is that this is not needed if you create a combo before any other gui element Thats all! I'm not talking about fixing it just to let you know about that. I've just chosen "bug" in the report (what else should i have done?). The doc btw. dont clarify that without the hight parameter the combo is broken on a W2k machine. At the end i must say im disappointed While reaching a helping hand i'm called stupid and better should piss off
- 10:00 AM Ticket #1382 (Windows 7 Taskbar API) updated by
-
Version changed
Automatic ticket cleanup. - 9:38 AM Ticket #1382 (Windows 7 Taskbar API) created by
- Hi, I'd like to have this included in AutoIt: …
- 9:30 AM Ticket #1381 (_ArraySearch subindex default doesn't match definition) created by
- Array.au3 : […] Array.au3 comment block: […] AutoIt 3.3.2.0 …
- 6:00 AM Ticket #1380 (Inform user of required parameters in _Timer_Settimer()) updated by
-
Version changed
Automatic ticket cleanup. - 4:57 AM Ticket #1380 (Inform user of required parameters in _Timer_Settimer()) created by
- Perhaps a remark could be added to help file to inform the user that …
- 4:24 AM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- And here I was, raring to go and test that DLL should the need have arisen ;P Anyhow, good to see that it's settled then!
- 2:52 AM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- After looking at how AutoIt works and doing some reading I've determined the following: parameters are always pushed onto the stack in the size of the architecture. On x86 every parameter <= 4 bytes takes up 4 bytes and on x64 every parameter <= 8 bytes takes up 8 bytes (even a char parameter). It should be obvious that if the structure is expected to be 8 bytes large with two distinct values aligned on 4-byte boundaries but x64 pads the values apart that things won't work - exactly as you determined. Your fix seems correct. The data must be packed into an 8 byte (64-bit) integer in order to prevent stack-alignment issues and preserve the expected structure alignment.
- 1:29 AM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- I definitely see something in the code that could be causing this. I may not need help as I think I can reproduce the problem myself on 32-bit Windows using a custom DLL.
Dec 30, 2009:
- 11:31 PM Ticket #1379 (compiling...) closed by
- Rejected: The forum is for asking questions. The forum is also for doing research to find similar subjects to get an idea of what our potential plans might be someday down the road.
- 11:19 PM Ticket #1365 (Windows 2000: GUICtrlCreateLabel before GUICtrlCreateCombo prevent ...) updated by
- I went to all the trouble of installing Windows 2000 to a virtual machine to test your stupid script. Immediately after the I spent a half hour getting that taken care of I noticed you weren't even specifying a height parameter in your example script. What you're saying is we should rewrite the code or rewrite the documentation (Documentation that already documents the problem you had!) because you can't be arsed to do what the documentation says and specify a proper height parameter? I easily reproduced your problem on Windows 2000 and the moment I ran a script with a proper height setting it started working. What I'm saying in short is this: Write good code that conforms with the documentation the language provides or piss off. Failing to heed the remarks in the documentation, having those remarks pointed out then telling us to fix it anyway is just asinine to put it mildly. There is no bug here. Everything is working as designed with the idiosyncrasies of different Windows versions. It's fully documented as well. Subject closed.
- 10:00 AM Ticket #1379 (compiling...) updated by
-
Version changed
Automatic ticket cleanup. - 8:58 AM Ticket #1365 (Windows 2000: GUICtrlCreateLabel before GUICtrlCreateCombo prevent ...) updated by
- I know Autoit is free ... Under Windows XP/2003 Windows will adjust the size of the opened combo. On other Windows versions you can define this size with the "height" parameter if the default value is not BIG enough to contain at least one line. But than this problem must occur at any time not only if i had another gui element in front of a Combobox If i "initialize" my combo first and then later reset the Pos and add infos to it it will work If you dont want to change it 'couse you need to rewrite a lot of code add this info in big red letters into the doc This script will work on W2k and XP ---------------------------------------------------- Opt("GUIOnEventMode", 1) #include <GUIConstants.au3> GUICreate("My GUI combo") $test = GUICtrlCreateCombo( "item1", 1, 1) $test2 = GUICtrlCreateCombo( "", 1, 1, 1 ) GUICtrlCreateLabel( "This is a test", 10, 10 , 150, 20) GUICtrlSetBkColor( -1, 0x00ff00) GUICtrlSetPos( $test, 20, 35 ) GUICtrlSetData( $test, "item2|item3", "item3") GUICtrlSetPos( $test2, 20, 150, 150 ) GUICtrlSetData( $test2, "native|pentium|pentium3|pentium-m|pentium4|prescott|nocona|core2|athlon-xp|k8|k8-sse3|amdfam10" ) GUISetState() while 1 sleep(5000) wend ----------------------------------------------------
- 8:46 AM Ticket #1379 (compiling...) created by
- So right now, AutoIt is interpreted. How much word would to take to …
- 12:16 AM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- Sure thing :)
Dec 29, 2009:
- 11:37 PM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- I cannot imagine anything that can be causing the size to change short of a bug in the handling of the "long" type. I will review the code tomorrow. Failing to find anything there, would you be willing to test a simple custom DLL written by me which mimics the input for WindowFromPoint() and reports what it actually receives?
- 10:52 PM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- (Uh, sorry, failed to change my username above. That was indeed me, the original poster)
- 10:51 PM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- To add a bit more information (in case this is relevant): I'm running Windows 7 Professional x64. I tried your suggestion, but saw no relevant difference. From a few further tests, it indeed seems like the Y member (the second value in the parameter passed to WindowFromPoint) is the one getting thrown out. How I tested this was to place a window at the very top edge of the screen (so that it covers the desktop even when the Y coordinate is 0). When I do that, I can see the handle shown in the example script's tooltip change exactly when I mouse over an X coordinate that the window covers, no matter what the mouse's actually Y coordinate is (that is, even if the mouse cursor is placed below the bottom edge of the window). The fixed (hacked) function reveals that the value of the handle I see is indeed the value of the window that I placed at the top edge of the screen. (Note: When I use your suggestion with my test, the only difference is that the tooltip shows the different handle when the mouse's Y coordinate is equal to an X coordinate that the window is covering at the top of the screen -- basically, the screen coordinates are transposted, as expected) This is pure conjecture, but I think the following quote from the KB article I linked to in the ticket description might be relevant (and perhaps, match your suspicions about calling conventions): > Another important consideration is that 32-bit Visual Basic uses the C convention (stdcall) of passing parameters. This convention specifies that arguments are placed on the stack from right to left. 16-Bit Visual Basic maintains the Pascal convention of passing parameters from left to right. (API functions are declared using the Pascal calling convention.) As a result, the elements of the structure must be listed in reverse order (that is, element y followed by x) when calling the WindowFromPoint function using 32-Bit Visual Basic. When using 16-bit Visual Basic, element x is passed to the API function before element y. I understand the POINT structure as defined in StructureConstants.au3 ("long x;long y") would still be a 64-bit structure composed of two 32-bit long integers, but I'm not sure if that actually helps, since as I understand it (admittedly not completely), AutoIt can't pass structures by value. To expand on my previous point about "padding" to x64, this is how _WinAPI_WindowFromPoint() currently calls "WindowFromPoint" in user32: […] Would this at all cause a 64-bit integer to be placed on the stack when it extracts the components from the DllStruct and passes the extracted value along to DllCall?
- 10:43 PM Ticket #1365 (Windows 2000: GUICtrlCreateLabel before GUICtrlCreateCombo prevent ...) closed by
- No Bug: Please read the documentation for GUICtrlCreateCombo().
- 10:23 PM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- What happens if you reverse the X and Y points on x64? There's no reason at all for the behavior you describe. The size of a POINT structure on x64 is still 64-bits composed of two 32-bit signed integers. The only thing I can think of is if the calling convention is different on x64 (I can't see any sign that it is, however). This would cause the values to be flipped. So, try flipping them yourself (fill the X member with the Y data and the Y member with the X data).
- 9:25 PM Ticket #1377 (Help file - _ColorGet* functions) closed by
- Fixed: Fixed by revision [5488] in version: 3.3.3.0
- 9:18 PM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) updated by
- This ticket is referenced in revision: [5487]
- 9:16 PM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) closed by
- Fixed: Fixed by revision [5486] in version: 3.3.3.0
- 11:09 AM Ticket #1378 (Wrong error handling in _Date_Time_SetLocalTime) created by
- Few functions in «Date.au3» (_SetDate and _SetTime) calls …
- 3:07 AM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) updated by
- I have already fixed some issues with that program that are probably related to your issue.
- 12:16 AM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) updated by
- Double quoting the command and not $(CurrentWord) exhibits the same odd behavior. Double quoting the command does not seem to make any difference as long as $(CurrentWord) is quoted. I guess some debugging of the Autoit3Help.exe helper app might be needed.
Dec 28, 2009:
- 11:36 PM Ticket #934 (MouseGetCursor consumes left mouse clicks) updated by
- Sorry - still occurs when using autoIt COM control - I downloaded 3.3.2.0. I went ahead and made my own COM .dll using VBExpress2008 (had to register it using .NET regasm.exe and gacutil.exe to make it COM visible). And it works *great* with no double click cancelling - but it doesn't return the same set of numbers you have (e.g. Arrow returns 65553). Please see if the following Class code helps you to make the AutoIt one work. Public Class cursorData Public Declare Function GetCursorInfo Lib "user32.dll" (ByRef pc As CURSORINFO) As Integer Structure CURSORINFO Dim cbsize As Integer Dim flags As Integer Dim hCursor As Integer Dim p As PointAPI End Structure Structure PointAPI Dim X As Integer Dim Y As Integer End Structure Public Function cursorType() Dim ff As New CURSORINFO ff.cbsize = System.Runtime.InteropServices.Marshal.SizeOf(GetType(CURSORINFO)) GetCursorInfo(ff) cursorType = ff.hCursor End Function End Class
- 6:12 PM Ticket #1375 (An array element alias) closed by
- Rejected: What you're asking for is called a dictionary or associate array. There are no plans to implement it.
- 5:11 PM Ticket #1377 (Help file - _ColorGet* functions) created by
- The Help file states that the parameter for the _ColorGet* …
- 4:12 PM Ticket #1376 (FileOpen()) created by
-
Please make in
FileOpen($Filename, $Mode)‘mode’ parameter … - 3:53 PM Ticket #1375 (An array element alias) updated by
-
Sorry, correct text
$array['elem'] - 3:51 PM Ticket #1375 (An array element alias) created by
- Will be useful, if there will may create alias name for an array …
- 2:50 PM Ticket #1374 (FileGetShortName returns wrong result on Win7) updated by
- Me bad :(, just did not associate .par with the exe-file on my freshly installed machine... thanks and closed.
- 1:14 PM Ticket #1374 (FileGetShortName returns wrong result on Win7) closed by
- No Bug
- 11:35 AM Ticket #1374 (FileGetShortName returns wrong result on Win7) updated by
- Thanks for the Test :), maybe it just worked for me on XP because I tested it in XP VM Mode and didn't check @error... Yep, that's it, im XP-VM Mode @error is 1.
- 10:59 AM Ticket #1374 (FileGetShortName returns wrong result on Win7) updated by
- When the file exists it returns the following on WinXP SP3: c:\test.par2 c:\TEST~1.PAR When the file doesn't exists it will return the same as the input but the @error = 1 Jos
- 10:40 AM Ticket #1374 (FileGetShortName returns wrong result on Win7) created by
- $sFilename = "c:\test.par2" $output = $sFilename & @crlf & …
- 6:00 AM Ticket #1373 (filecopy filemove with independent thread) updated by
-
Version changed
Automatic ticket cleanup. - 5:16 AM Ticket #1373 (filecopy filemove with independent thread) created by
- filecopy filemove with independent thread. like inet func,return a …
- 2:57 AM Ticket #1367 (GUIDelete() crashes program when called from WM_* message handler) closed by
- Fixed: Fixed by revision [5485] in version: 3.3.3.0
- 2:31 AM Ticket #1370 (StringInStr()) closed by
- Fixed: Fixed by revision [5484] in version: 3.3.3.0
- 2:21 AM Ticket #1370 (StringInStr()) updated by
- These two are returning the correct result: […] An invalid start parameter is one that is <= 0: […] The crashing should not happen and will be fixed.
- 2:15 AM Ticket #1372 (HTTPSetUserAgent bad description) closed by
- Fixed: Fixed by revision [5483] in version: 3.3.3.0
Dec 27, 2009:
- 11:50 PM Ticket #384 (More extensive testing of RunAs()) updated by
- This ticket is referenced in revision: [5482]
- 11:14 PM Ticket #384 (More extensive testing of RunAs()) updated by
- Vindication! There *was* a really obscure bug nobody but me would ever find.
- 11:13 PM Ticket #384 (More extensive testing of RunAs()) closed by
- Fixed: Fixed by revision [5480] in version: 3.3.3.0
- 8:34 PM Ticket #1372 (HTTPSetUserAgent bad description) created by
- Help file only says that it works with InetGet() But it works with …
- 6:20 PM Ticket #1371 (_TempFile() update) updated by
- There is no need for the code to explicitly test -1.
- 6:00 PM Ticket #1371 (_TempFile() update) updated by
-
Version changed
Automatic ticket cleanup. - 5:41 PM Ticket #1371 (_TempFile() update) created by
- Add this in _TempFile() to accept "Default" keyword or -1 value […]
- 5:19 PM Ticket #1369 (Static.au3 example not working) closed by
- No Bug: As the documentation says, Static isn't finished so reporting bugs on it is stupid.
- 4:50 PM Ticket #1370 (StringInStr()) created by
- […]
- 3:02 PM Ticket #1369 (Static.au3 example not working) created by
- Trying out the new Static keyword, I looked at the help file, and …
- 1:52 AM Ticket #1368 (_ClipBoard_GetData($CF_BITMAP) not working on 3.3.2.0) updated by
- I've just spent awhile debugging this. Here's what I've concluded: * The reason the function fails is due to the call to _MemGlobalLock() returning error 6 (Invalid handle) when used on the handle returned for $CF_BITMAP. * I think the reason _MemGlobalLock() is failing is because rather than a handle to global memory I believe the handle is actually an HBITMAP. The difference's between 3.3.0.0 and 3.3.2.0 are: * In 3.3.0.0 _Clipboard_GetData() returned the handle that GetClipboardData() returned. This is not safe. Once the clipboard data changes that handle becomes invalid or points to different data entirely. This could actually lead to an application crash. * In 3.3.2.0 _Clipboard_GetData() tries to copy the data and returns the copy. However, not all of the data is stored in the same way so the generic code fails on certain data formats. The key problem is: _Clipboard_GetData() is doing too much. It was designed to handle opening and closing the clipboard for the user and was supposed to do the right thing. Except it's pretty much a failure since it doesn't know what the right thing is. _Clipboard_GetData() needs to be a thin wrapper around GetClipboardData() and not try anything fancy. Right now the thin wrapper is actually at _Clipboard_GetDataEx(). These functions should have been swapped from the beginning to match the API and the standard convention of "Ex" functions doing more. As it stands the solution is to make _Clipboard_GetData() a thin wrapper meaning to use it you will have to manually call _Clipboard_Open() and _Clipboard_Close(). Then _Clipboard_GetDataEx() can be modified to provide custom handling for specific formats (for example, it's trivial to open the clipboard, retrieve text into a buffer and close the clipboard returning the text). In short, the fix for this is likely to be swapping _Clipboard_GetData() and _Clipboard_GetDataEx() and _Clipboard_GetDataEx() will only work with a few clipboard formats that have common actions (like the above text example).
- 1:02 AM Ticket #1366 (TrayCreateItem() bug) updated by
- Please read WikiStart to learn how to properly report a bug. You have failed to provide a script to reproduce the issue.
- 12:58 AM Ticket #1343 (Docs spelling error > _GUICtrlTreeView_SetIcon.htm) closed by
- Fixed: Fixed by revision [5477] in version: 3.3.3.0
Dec 26, 2009:
- 8:04 PM Ticket #1368 (_ClipBoard_GetData($CF_BITMAP) not working on 3.3.2.0) created by
- this code workes fine on AutoIt 3.3.0.0, but returns zero (no …
- 6:18 PM Ticket #1367 (GUIDelete() crashes program when called from WM_* message handler) created by
- GUIDelete() crashes the autoit compiled executable and also the …
- 4:08 PM Ticket #1366 (TrayCreateItem() bug) created by
- TrayCreateItem(text [, menuID [, menuentry [, menuradioitem]]]) works …
- 12:47 PM Ticket #1365 (Windows 2000: GUICtrlCreateLabel before GUICtrlCreateCombo prevent ...) created by
- This is a very old bug (3.1.1.127 own this bug too) If ( a …
Dec 25, 2009:
- 8:08 PM Ticket #1364 (IniReadSection update) closed by
- Duplicate: No shit? I guess #15 isn't good enough?
- 8:00 PM Ticket #1364 (IniReadSection update) updated by
-
Version changed
Automatic ticket cleanup. - 6:09 PM Ticket #1364 (IniReadSection update) created by
- IniReadSection ( "filename", "section" ) Only the first 32767 chars …
- 5:58 PM Ticket #1363 (FileSetPos() error) created by
- FileSetPos($hFile, $num, $FILE_CURRENT) works incorrectly. Result is …
Dec 24, 2009:
- 5:23 AM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by
- As an aside, I'm not sure how many other Windows API functions actually expect POINT structures to be passed by value, but if there are any other UDFs that rely on such functions, they may need to be fixed as well.
- 5:16 AM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) created by
- Indeed, I've seen #974, but I think the problem I'm addressing is …
Dec 23, 2009:
- 8:32 PM Ticket #1359 (Embed a file in compiled script) closed by
- Rejected
- 7:55 PM Ticket #1361 (_SetTime() and _SetDate() crash when accessing non-array) created by
- Here's the trace: […] I suggest changing two lines of code: 2245: …
- 6:55 PM Ticket #1360 (for what are these files) created by
- I think you doesn`t need these two file for the help file: …
- 3:43 AM Ticket #1344 (_WinAPI_CreateFile - Use of magic number and resulting 64-bit ...) updated by
- Well I checked the change logs and there was no mention there so I assumed that would be sufficient. Granted it is an old version date wise, but it was the latest stable release at the time I filed the report. Perhaps there should be a note on the main page of the bug tracker to check the beta's incase the change isn't listed in the change log or something? Regardless, this isn't a forum so I'll leave it be.
Dec 22, 2009:
- 8:29 PM Ticket #1359 (Embed a file in compiled script) updated by
- Why not simply use FileInstall() ? Jos
- 8:22 PM Ticket #1359 (Embed a file in compiled script) created by
- It would be nice to be able to embed a file into the compiled autoit …
- 7:18 PM Ticket #1344 (_WinAPI_CreateFile - Use of magic number and resulting 64-bit ...) updated by
-
Milestone changed
Ugh, so you filed a bug report against an old version not bothering to test that it was fixed in the betas? - 6:35 PM Ticket #1348 (aut2exe Mangles Named RCDATA Resources) updated by
- Not sure if we really want to support modifying the BIN files but leave that up to Jon to decide. The current solution we are working on to update the resources after compilation is the way to go. Jos
- 6:00 PM Ticket #1344 (_WinAPI_CreateFile - Use of magic number and resulting 64-bit ...) updated by
-
Milestone changed
Automatic ticket cleanup. - 4:34 PM Ticket #1344 (_WinAPI_CreateFile - Use of magic number and resulting 64-bit ...) closed by
- Fixed
- 2:11 PM Ticket #1325 (Date.au3: calls to _Date_Time_SetLocalTime($pSystemTime) are not ...) updated by
- There are still two pieces of code in Date.au3 that concern me: […] If @error is 0 but the second condition is met for each of those OR statements, then 0 will be returned in @error and the calling function may still try to access the array since it will only check for @error. I think it should explicity set @error or all the calling programs need to use isArray() to make sure an array has been returned.
- 2:01 PM Ticket #1344 (_WinAPI_CreateFile - Use of magic number and resulting 64-bit ...) updated by
- Can be marked as fixed/closed. Fixed in 3.3.2.0
- 6:10 AM Ticket #1358 (FileCreateNTFSLink Example has mixed up Parameters) closed by
- Fixed: Fixed by revision [5469] in version: 3.3.3.0
Dec 21, 2009:
- 11:07 PM Ticket #1358 (FileCreateNTFSLink Example has mixed up Parameters) created by
- In section "Examples" of FileCreateNTFSLink are parameters "source", …
- 9:50 PM Ticket #1357 (New concatenation operator for Static) updated by
- I just pointed to a possible problem that could come up when, and if, Static would be non-experimental. This appeared to be the best place to do that. You didn't see that? Don't bother answering. I did. Sorry for possible inconvenience. Wasn't intended.
- 9:12 PM Ticket #1357 (New concatenation operator for Static) updated by
- Also, I just grasped what you wanted. Absolutely positively not. This is such a terrible idea to work around a problem that's completely unrelated. Just, no.
- 9:11 PM Ticket #1357 (New concatenation operator for Static) closed by
- Rejected: I guess you didn't bother to read this very large message in the documentation? […] The feature is not complete, it contains bugs. Asking for new functionality for a feature that isn't even complete is just... annoying. Please wait until the feature is actually fully supported before trying to discuss it.
- 8:35 PM Ticket #1357 (New concatenation operator for Static) created by
- Special concatenation operator with new Static is missing. This …
- 9:35 AM Ticket #1346 (Send doesn't work with windows opened under another user) updated by
- Replying to Valik: > Okay, so this time you actually provided the crucially important "WinTitleMatchMode" line which fixes the mistake I found in your first attempt. Now that you've corrected that... it works just fine. I plugged in suitable account credentials for my Windows XP SP3 machine, Notepad popped up as the other user and the file menu appeared. Dear Valik, I have used AutoIt for 8 years, so "WinTitleMatchMode" I use automatically, thas why I didn't put it in source code.:-) Well, I didn't tested it on XP. I moved to Windows Vista Enterprise, SP1. Maybe problem will be something with UAC. I tried 3 computers with Microsoft Vista, the same result - it doesn't work.
- 12:56 AM Ticket #1354 (sqlite function problem...) updated by
- Replying to anonymous111: > I updated autoit from v3.3.0.0 to v3.3.2.0. > but, extracted korean characters from my sqlite db are all broken. anonymous111, Drop me a pm or post in the user help forum and I'll help you with this issue.
Dec 20, 2009:
- 9:58 PM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) created by
- The data that we want is squashed over to the far right in the …
- 9:57 PM Ticket #1352 (StringSplit hard crash on binary data) updated by
- I test under XP/Sp2 with the file you reference in your script. I test with one script by process.
- 9:27 PM Ticket #1355 (Data types mixed) reopened by
- Ugh.
- 2:07 PM Ticket #15 (Rewrite INI functionality to remove limitations.) updated by
- Ref: Support topic: Array limited http://www.autoitscript.com/forum/index.php?showtopic=107138 This appears to be mostly fixed. I scripted a couple of demos working with >300KB ini file, and most things worked fine. The one that didn't work was IniReadSection() with huge individual sections.
- 10:59 AM Ticket #1355 (Data types mixed) updated by
- Ok, I see that. This is a change in behavior. dword type with DllCall() no longer have sense, since it's treated as int. I can find my way thru Bit functions and will switch to that. Even though that slows scripts further. This ain't changed: […] It's a bad change from my perspective.
- 12:52 AM Ticket #1355 (Data types mixed) closed by
- No Bug: AutoIt displays all values as signed integers. The values you are working with are unsigned. The same bits are set in either case. This is not a bug.
Dec 19, 2009:
- 11:54 PM Ticket #1355 (Data types mixed) created by
- With new 3.3.2.0 version there are issue(s) with data types with …
- 11:58 AM Ticket #1352 (StringSplit hard crash on binary data) updated by
- >I cannot reproduce your pb under XP/SP2 see attach file Hm, strange... do you have the image file? or/and can you please test it on other image? P.S I tested each example in seperate process, for some reason when i put all three examples in one script i get other results (sometimes crashes, sometimes not, strange...).
- 9:33 AM Ticket #1352 (StringSplit hard crash on binary data) updated by
- I cannot reproduce your pb under XP/SP2 see attach file
- 8:54 AM Ticket #1338 (_arrayDisplay() GUI position error) closed by
- Fixed: Fixed by revision [5465] in version: 3.3.3.0
- 8:07 AM Ticket #1354 (sqlite function problem...) updated by
- Do you honestly think this is the correct way to submit a bug report?
- 7:49 AM Ticket #1354 (sqlite function problem...) created by
- I updated autoit from v3.3.0.0 to v3.3.2.0. but, extracted korean …
Dec 18, 2009:
- 9:55 PM Ticket #1353 (_FileWriteToLine() excessively strict on input text type) created by
- Reported by user anixon: …
- 8:34 PM Ticket #1352 (StringSplit hard crash on binary data) created by
- Theese examples will show that script is crashing when using …
- 12:49 PM Milestone 3.3.2.0 completed
Dec 17, 2009:
- 7:16 PM Ticket #1009 (Remove hard-coded calls to ConsoleWrite() in SQLite.au3) updated by
-
Owner, Status changed
- 6:06 PM Ticket #1346 (Send doesn't work with windows opened under another user) updated by
- Okay, so this time you actually provided the crucially important "WinTitleMatchMode" line which fixes the mistake I found in your first attempt. Now that you've corrected that... it works just fine. I plugged in suitable account credentials for my Windows XP SP3 machine, Notepad popped up as the other user and the file menu appeared.
- 1:55 PM Ticket #1346 (Send doesn't work with windows opened under another user) updated by
- Replying to Valik: > I suggest you debug your code a bit further. There is a mistake in your code and once you correct that it will work just fine. Dear Valik, thanks for reply, the code is not complete, but I spend half hour with this issue, so I thing it has to be a bug:-) […]
Dec 16, 2009:
- 9:18 PM Ticket #1351 (Why "text" = 0 ?) closed by
- No Bug: Use the forum to ask questions.
- 8:46 PM Ticket #1351 (Why "text" = 0 ?) created by
- Environment = 3.3.0.0 under WIN_XP/Dodatek Service Pack 2 X86 […] …
- 6:27 PM Ticket #1350 (Obfuscator line excludes) closed by
- Rejected: This is implemented already. […] Ask support via the forum.
- 5:37 PM Ticket #1349 (InetGet not working without Filename) closed by
- No Bug: Feedback? If you want feedback then you ask on the forum. Where you would have been told this is not a bug.
- 5:00 PM Ticket #1350 (Obfuscator line excludes) updated by
-
Version changed
Automatic ticket cleanup. - 4:41 PM Ticket #1350 (Obfuscator line excludes) updated by
- #Obfuscator_Ignore_Variables not working
- 3:33 PM Ticket #1350 (Obfuscator line excludes) created by
- there are two lines in my code where I am comparing strings and the …
- 2:44 PM Ticket #1348 (aut2exe Mangles Named RCDATA Resources) updated by
- Actually I found the bug while modifying AutoIt3Wrapper to use named resources, and just confirmed it with ResHacker. Took me hours to figure out what was going on until I interrupted the process and looked at the interim .bin file :/
- 11:08 AM Ticket #1349 (InetGet not working without Filename) created by
- There is no network communication for InetGet if the optional …
- 9:34 AM Ticket #1348 (aut2exe Mangles Named RCDATA Resources) updated by
- Just some notes: 1)As workaround you can add desired resources to output compiled EXE instead of AutoItSC.bin. This way I add resources in my Resource UDF http://www.autoitscript.com/forum/index.php?showtopic=51103 […] 2) Scite4AutoIt3 has the similar bug. If you use #AutoIt3Wrapper_Res_File_Add directive then resource is placed at wrong section with wrong name
- 3:30 AM Ticket #1348 (aut2exe Mangles Named RCDATA Resources) created by
- If I add a named resource to AutoItSC.bin with ResHacker, then compile …
- 1:43 AM Ticket #1347 (Restoring cursor position after certain scite4autoit tools.) closed by
- Rejected: Since you still haven't offered any insight into what you are talking about I'm closing this.
- 12:16 AM Ticket #1347 (Restoring cursor position after certain scite4autoit tools.) updated by
- >Let me spent as much time on this request as you: I seriously thought that. but thats my problem and not yours. 1. x hours juggling with a possible reply. 2. noticing that, despite the mental note about it, I still managed to drop in the wrong shortcut. 3. one minute between reply's? nevermind, I know I deserve it.
Dec 15, 2009:
- 7:42 PM Ticket #1347 (Restoring cursor position after certain scite4autoit tools.) updated by
- Let me spent as much time on this request as you: ... Sorry, thats it.
- 7:41 PM Ticket #1347 (Restoring cursor position after certain scite4autoit tools.) updated by
- And you are referring to what specifically?
- 7:26 PM Ticket #1347 (Restoring cursor position after certain scite4autoit tools.) created by
- Making them feel more like how scite's own 'duplicate'(alt-d) tool …
- 5:56 PM Ticket #1345 (3.3.1.7 Number("35.") returns 0) updated by
-
Milestone changed
Fixed by revision [5457] in version: 3.3.2.0 - 5:55 PM Ticket #1345 (3.3.1.7 Number("35.") returns 0) closed by
- Fixed: Fixed by revision [5456] in version: 3.3.3.0
- 5:42 PM Ticket #1346 (Send doesn't work with windows opened under another user) closed by
- No Bug: I suggest you debug your code a bit further. There is a mistake in your code and once you correct that it will work just fine.
- 3:28 PM Ticket #1346 (Send doesn't work with windows opened under another user) created by
- Send doesn't work with windows opened under another user. Following …
- 3:16 PM Ticket #1345 (3.3.1.7 Number("35.") returns 0) created by
- As the summary says, Number() used on a string that contains a number …
- 2:36 PM Ticket #1344 (_WinAPI_CreateFile - Use of magic number and resulting 64-bit ...) created by
- Said function tests for 0xFFFFFFFF (which equals INVALID_HANDLE_VALUE …
Dec 14, 2009:
- 6:09 PM Ticket #1343 (Docs spelling error > _GUICtrlTreeView_SetIcon.htm) created by
- In _GUICtrlTreeView_SetIcon.htm $iImageMode [optional] 2=normal image …
Dec 12, 2009:
- 9:08 PM Ticket #1342 (DllStructCreate does not accept variable names with underscore) closed by
- Duplicate: Replying to thomas.baglin@…: > Hoping I am not wasting your time :-) You are because you: * Didn't check the issue tracker to see it's already been reported. * Didn't test with the latest beta to see that it's already been fixed. Closing as duplicate of #1321.
- 8:31 PM Ticket #1342 (DllStructCreate does not accept variable names with underscore) created by
- $dllstruct=dllstructcreate("int titi_1") consolewrite("@error reported …
Dec 11, 2009:
- 11:16 PM Ticket #1341 (Win7 x64 - Cannot send any messages to dialog controls) created by
- Script here: Dim $total WinWaitActive("Progress Quest - New …
- 9:53 PM Ticket #1340 (Send("{ENTER}") in IE7) created by
- If I create a login script which simply uses Send for all functions: …
- 6:29 PM Ticket #1335 (_ColorConvertRGBtoHSL incorrectly normalised to 240) updated by
- It is now fixed so that Trac no longer misleadingly gives the impression you can re-open a ticket.
- 6:16 PM Ticket #1335 (_ColorConvertRGBtoHSL incorrectly normalised to 240) updated by
- Replying to anonymous: > I have at no time been rude or disrespectful to you, I would expect the same courtesy (did you not like your own words thrown back at you?). You haven't? As I said, you're a dick for thinking you have any say what-so-ever in re-opening our tickets. I honestly don't know why the reopen radio is showing up but it's not supposed to. As I said previously, it's people like you who can't even be arsed to read WikiStart that prevent us from letting users have that privilege. See the part of WikiStart where it says don't bloody argue on Trac, take it to the forum. So yeah, you're being quite rude, not even following our own rules about arguing here. > What gives you the right to speak to people like this? I'm sure you would be in violation of your own forum rules. Should we put it to the test? What gives you the right to determine what is and is not rude? Maybe I consider your incessant nagging rude? Did that ever occur to you Mr. High and Mighty? > Your hubris and bullying is quite disturbing. Your refusal to comprehend my posts is also quite disturbing. > Anyway on with the science. So my "fundamental arguments" are: > > 1. The function does not conform to it’s own specification in the help file. The function does NOT "work as advertised". You don't know what specification it's supposed to conform to. You've found an errant comment in the file and are trying to treat it as a specification. Here's a clue: Comments are sometimes irrelevant. I can't tell you the number of comments I've seen that don't pertain to the surrounding code because the code was changed and the comment was not. Get over it, it proves nothing other than your argument is so weak that you're grasping at straws. > > 2. Wiki and all it’s references say that H range [0,360] and S&L range [0,1]. > > 3. GIMP & Photoshop work as described above. H is in degrees and S&L in percent. You, yourself use this same standard. "What makes me special..."? Ask yourself, you're the one who doesn't use the function as written. I don't use the function at all so I don't really give a shit at all. And FYI, your comment about my usage should have fallen in #2 since I don't use percentages, I use decimal numbers (yeah yeah, just a * 100 away from being a percent). > 4. If this "standard" UDF is targeted at just MS Paint users then it should be labelled as such. For the average person who knows HSL theory (but never used Paint) this function is useless. They have to debug it first to work out why they are getting results not consistent with any documentation or industry standard. Your quotation of the word "standard" implies you don't understand what it really means in this context. It means they are standard AutoIt functions, not that they conform to some external standards body. > 6. Given all the above information, I don’t think that you or anyone else seriously believes that MS Paint color picker is (or should be) THE worldwide standard for HSL. I don't see anyone claiming it is or should be the worldwide standard. Hyperbole FTL. > We are not talking about programming. We are talking about a scientific principal relating to color. It’s still the same principal no matter if you coded it in C++, Excel or with pen and paper. We are talking about programming because your whiny hissy bitch-fit centers around the fact that the colors aren't represented how you want. You're clearly missing the point where programming choices about accepted input and output are related to the specific programming implementation and despite what you seem to think it's not a requirement by "god" or anyone else that this conform to any industry standard. > Having made your conclusions (that are not supported by science) I never claimed science supported anything. > your ego has left you no option but to continue making your case that "you are right and I am wrong". Oh, you mean what you are doing? With all your refusals to accept that you're just flat out wrong with every basic assumption you've made about the function? You are wrong in that it conforms to any standard and you are wrong in your assumption that it should conform to any standard. You are wrong in thinking anyone gives a shit about your "HSL theory" bullshit because chances are anybody else that cares will write their own damned function to work with whatever ranges they want instead of bitching their stupid ass off about how because they use standards they are cool or some other bullshit. Take your damned HSL standards and shove them up your ass. This function doesn't conform to them, it was never intended to conform to them as judged by the output and behavior so get over it and move the fuck along. Otherwise I'm taking the functions out of the language entirely. Is that what you want? For the functionality to be removed from users who like it because one whiny little know-it-all bitch can't accept that maybe the world doesn't revolve around them? > So bottom line is your ego will probably prevent you from reversing your decision and you'll probably think of some internally consistent way of justifying why you too do not use the function as written. I don't use the function as written because I don't need it. Shocking, I know. As for my ego? I think it's perfectly clear who's ego is bigger here. Here's a hint: I'm a custodian of the evolution of this language, not some puppet to be pulled around by arrogant dickwads who make incorrect assumptions and then argue until they are blue in the face about it. > As I pre-empted this outcome (based on your predictable attitude) I will probably release my own version of the UDF. It will be interesting to see the extent that you try to censure me. Maybe then the whole community can have an informed discussion about the science (as opposed to this bizarre defence of MS Paint). I may remove you for your attitude and your comments, not because of your code. As long as it falls within the reasonable bounds we've set for unacceptable content I don't give two shits what you post (nor about you for that matter). > In closing you would be well advised to re-read what you've written - it's quite ugly isn't it? I bet you'd be proud to show a future employer your achievements here - perhaps new users or companies thinking of using AutoIt? The messages they should take from this are: Oh goody. Now you're really shoving your foot down your throat. This will be fun to shred. > 1. Do not use features provided to you for fear of bullying and intimidation. Wrong. It's more like, "Do not bitch about features unless you are 100% sure of the intent behind them. You are clearly not sure of the intent behind the functions in question so you've raised a bitch fit over them for no reason. > 2. Those features will be taken away if used as intended. No, those features will be taken away if people incessantly bitch about them. > 3. Valik claims to be a part owner of the language. Where exactly has this been stated or implied? Or is this another one of the moronic conclusions you've jumped to? I have not nor have I ever claimed to be any portion of owner of the language. > 4. It is the developer’s absolute right to behave appallingly in contravention of his own forum rules. Intelligent adults are expected to accept this behaviour “or leave”. No, intelligent adults are expected to understand what the fuck they're talking about before they go on long rants. Those who miss the point are usually taken to task for it. > 5. Discussing legitimate scientific inaccuracies is “stupid” and grounds for being verbally abused. Again, you miss the point. Your scientific reasoning is meaningless when it's not relevant to the intent of the function in question. > 6. The apparent bug is invalid if it works in the one (obscure) program the developer uses. Or basically any program that uses the Windows color picker. But anyway, in case you didn't notice, we accept contributions from the community. Somebody thought the function would be useful so they submitted it. I can't really justify the existence of the visa library in AutoIt because that seems even more niche than HSL but there it is. Should we change to a policy where we accept nothing? Would that make you happy? > 7. The fact that the software does not conform to its own written specification is not a bug. The only problem with this statement is that you don't know what specification the function is supposed to conform to. You're jumping to conclusions based on a comment in the source and perhaps a documentation link failing to realize that maybe the function changed and the other material is out-of-date. > 8. All scientific literature and industry standards will be ignored at the discretion of the developer if it “doesn’t interest him”. They are ignored when they are not relevant. Trying to make them relevant as an argument for why something that was never intended to work how you want should work how you want is not dismissal. It just means it's not relevant. Astounding. > Interestingly this post also went "missing" after I saw it published on the page, lucky I had a backup. If you are attempting to make some implication that it was censored then you are wrong. I'd much rather take you to task in public than remove something. I only remove things like offensive images or links to things that shouldn't be linked to. I leave user stupidity and my responses to it for all to see. Now, to wrap this up. It's time to play what I'm sure will be called a "power trip" card. This subject is closed. Further discussion on this will result in your removal from the site for awhile. My fundamental reason for doing this is: 1. You are clearly violating the issue tracker guidelines by inciting this argument here. 2. Your entire premise, your justifications and arguments are based around assumptions you have made that this function should be standard or conform to an industry standard. These assumptions are wrong. It's clear to me that the author's intent was to provide HSL functions for working with colors as represented in the standard Windows color picker dialog. No more, no less. 3. If you have issue with the functions you should have just said "the documentation should mentioned this is how these functions work". Nobody needs these long Wikipedia quotes explaining HSL beccause quite honestly the only person who cares is you.
- 12:00 PM Ticket #1335 (_ColorConvertRGBtoHSL incorrectly normalised to 240) updated by
- I have at no time been rude or disrespectful to you, I would expect the same courtesy (did you not like your own words thrown back at you?). What gives you the right to speak to people like this? I'm sure you would be in violation of your own forum rules. Should we put it to the test? The reopen function is available to me as a user and I clicked it. Why do you make it available otherwise? If someone spoke to you like that for using features given to you and you were trying to help improve the program, what would you think of “YOU” and “YOUR” language? Your hubris and bullying is quite disturbing. Anyway on with the science. So my "fundamental arguments" are: 1. The function does not conform to it’s own specification in the help file. The function does NOT "work as advertised". 2. Wiki and all it’s references say that H range [0,360] and S&L range [0,1]. 3. GIMP & Photoshop work as described above. H is in degrees and S&L in percent. You, yourself use this same standard. "What makes me special..."? Ask yourself, you're the one who doesn't use the function as written. 4. If this "standard" UDF is targeted at just MS Paint users then it should be labelled as such. For the average person who knows HSL theory (but never used Paint) this function is useless. They have to debug it first to work out why they are getting results not consistent with any documentation or industry standard. 5. If, for some reason, normalising to 240 is some obscure programming requirement in windows (changing background or whatever), then those people should know they have to normalise and they can adjust manually. 6. Given all the above information, I don’t think that you or anyone else seriously believes that MS Paint color picker is (or should be) THE worldwide standard for HSL. 7. QUOTE “If you want to argue the output is "wrong" then I'll just point you to my above statement where I already mentioned two different variations on the format I have personally used and ask you what makes you so special that you get to determine which format we use?” a) Please provide the reference for the MS Paint method along with your objective arguments for using it as a STANDARD. b) Please define “we” as in… How many people serious about color use Paint? If by “we” you mean “us programmers” then the function does not belong under “color” it belongs somewhere else where people actually care that windows works in 240. 8. QUOTE “But all the methods are valid representations [of C++ code].” We are not talking about programming. We are talking about a scientific principal relating to color. It’s still the same principal no matter if you coded it in C++, Excel or with pen and paper. Having made your conclusions (that are not supported by science) your ego has left you no option but to continue making your case that "you are right and I am wrong". I appreciate that you probably have vast knowledge when it comes to programming and I also appreciate that you are not expected to be an expert in everything that we might use computers for. So bottom line is your ego will probably prevent you from reversing your decision and you'll probably think of some internally consistent way of justifying why you too do not use the function as written. As I pre-empted this outcome (based on your predictable attitude) I will probably release my own version of the UDF. It will be interesting to see the extent that you try to censure me. Maybe then the whole community can have an informed discussion about the science (as opposed to this bizarre defence of MS Paint). In closing you would be well advised to re-read what you've written - it's quite ugly isn't it? I bet you'd be proud to show a future employer your achievements here - perhaps new users or companies thinking of using AutoIt? The messages they should take from this are: 1. Do not use features provided to you for fear of bullying and intimidation. 2. Those features will be taken away if used as intended. 3. Valik claims to be a part owner of the language. 4. It is the developer’s absolute right to behave appallingly in contravention of his own forum rules. Intelligent adults are expected to accept this behaviour “or leave”. 5. Discussing legitimate scientific inaccuracies is “stupid” and grounds for being verbally abused. 6. The apparent bug is invalid if it works in the one (obscure) program the developer uses. 7. The fact that the software does not conform to its own written specification is not a bug. 8. All scientific literature and industry standards will be ignored at the discretion of the developer if it “doesn’t interest him”. _ Endnote: I notice you found my “missing” post. This post was written while that post was thought missing, hence the repetition. Interestingly this post also went "missing" after I saw it published on the page, lucky I had a backup.
- 8:53 AM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) reopened by
- It actually would make more sense to me when we double-quote the command itself. could you try that for me as i have no issues on my installation? command.help.$(au3)="$(autoit3dir)\Autoit3Help.exe" $(CurrentWord) Thanks Jos
- 3:41 AM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) updated by
- Sorry, I forgot about this thread until today (no notifications of replies to trac tickets). Anyway, I fixed the problem, but I don't know why exactly. All I was doing was pressing F1 while the caret was within a keyword in Scite. I had to swap these two lines in au3.properties. Originally (the installation default) the command without quotes was active, and I had to swap it to activate the line with quotes. Win7 Pro 32-bit Scite 1.79 AutoIt 3.3.1.7 […]
- 1:26 AM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) updated by
- I'll keep that in mind from now on :) Thanks, Daniel
Dec 10, 2009:
- 11:08 PM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) updated by
- If a bug is fixed in a newer version of AutoIt (beta or otherwise) then it's fixed as far as we are concerned. Unless it's "OMG super critical" then we don't back-port fixes. Users are always encouraged to use the latest stable version as their default version and to test the latest beta as much as possible (Hence the ability to do side-by-side installs). When new release are made users are expected to read the changelog and upgrade accordingly.
- 11:04 PM Ticket #1335 (_ColorConvertRGBtoHSL incorrectly normalised to 240) updated by
- FYI: You just replied to a closed ticket, quite obviously. Anyway, I just read your reply (I do not know why it was rejected) and all I have to say is what an arrogant prick you are to think you can re-open a ticket. It's people like you who think they know everything and wish to argue with us about our language and fight us by re-opening tickets that prompted us to disable the ability to open tickets in the first place. This is our language and our issue tracker and if we want to close a ticket, well, fuck you because it's not your place to tell us what we should or should not do with our language. With that out of the way, let's move on. I don't know why you are arguing such a stupid thing. It's perfectly clear and you know this based on your other post that HSL values are typically represented in a couple different ways. I use either floats in the range 0.0 - 1.0 or a slight variation where the Hue is an integer in the range 0 - 360. Why the author chose to write to something else doesn't really interest me. It is what it is and just because it doesn't get your jollies off doesn't mean it's wrong. And yeah, I've checked other references. Like the C++ code I wrote to convert from HSL in the two aforementioned representations to RGB. I saw the code was different so I tested with the easiest program I had available. It gave the same results as MSPaint which says to me the user wrote the code to do conversions for MSPaint (and all programs using the standard Windows color picker). Fine with me. So what is your fundamental argument? That it doesn't work... or that it doesn't give the output you want? From what I can tell your whole issue is the latter because the function certainly works as advertised. If you want to argue the output is "wrong" then I'll just point you to my above statement where I already mentioned two different variations on the format I have personally used and ask you what makes you so special that you get to determine which format we use? Notice I didn't mention expressing HSL as degrees and percents - because I didn't use that representation in my C++ code. But all the methods are valid representations.
- 10:50 PM Ticket #1339 (Update helpfile translations links) updated by
- http://autoit.de/hilfe for recent German files. Thanks for adding!
- 10:35 PM Ticket #1335 (_ColorConvertRGBtoHSL incorrectly normalised to 240) updated by
- I originally wrote a reply to this. Took a lot of time. Was all wasted because we can't post replies to closed bugs? Would be good to be informed of this before the user wastes their time. Would also be good if you consulted the user as well before making conclusions based your flawed research. Did you check other references - Help, Wiki, Photoshop, GIMP, HSL theory which has been around long before MS Paint? What makes you think they are wrong? Because they are not. ---- Valik Edit: Below is the original post copied from the logs ---- And what happens when you type 300 in GIMP (open source alternative to Photoshop)? H range [0,360] (angle) and S&L range [0,100] (percent). I don't have Photoshop but my cursory googling showed that Photoshop operates in exactly the same way. The help documentation for _ColorConvertRGBtoHSL states: […] Note "HSL results from 0 to 1" and the absence of normalising to “MS Paint color picker”. So the function does not conform to it's own specification. I'm quite sure that's called a bug. The standard according to Wiki and it's references is: H range [0,360] S&L range [0,1] "Why do you think these references are wrong? Because they are not." If this "standard" UDF is targeted at just MS Paint users then it should be labelled as such. For the average person who knows HSL theory (but never used Paint) this function is useless. They have to debug it first to work out why they are getting results not consistent with any documentation or industry standard. If, for some reason, normalising to 240 is some obscure programming requirement in windows (changing background or whatever), then those people should know they have to normalise and they can adjust manually. I'm reopening this because I don't think you or anyone else would seriously believe MS Paint color picker is (or should be) THE worldwide standard for HSL.
- 10:26 PM Ticket #1338 (_arrayDisplay() GUI position error) updated by
- I've had a closer look at the code for the _arrayDisplay() function and offer the line indicated below as a possible fix. […]
- 10:11 PM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) updated by
- I tracked down the problem, and it's not Windows 7-only, it is actually x64-only: the menuitem structs were using 'int' instead of 'handle' or 'ptr', which obviously doesn't work. I only reported this bug because I think others may run into it, and it'd be nice if it's documented somewhere (since it doesn't seem to be enough to warrant a maintenance release or something like that) that a whole UDF doesn't work in the stable version, since that's what most people actually use. I understand you may not want to back-port the fix, but I had no way to know it: it's a common practice, specially when the next version is expected to take a while to be adopted due to major changes (e.g., Python 2 is still maintained because of the thousands of scripts that won't, nor should, be forcefully ported to Python 3).
- 9:12 PM Milestone 3.3.1.7 completed
- 9:05 PM Ticket #1339 (Update helpfile translations links) created by
- Hi, if there is some time available, these links should be updated. …
- 8:22 PM Ticket #1338 (_arrayDisplay() GUI position error) created by
- The _arrayDisplay() function calculates a very poor GUI location when …
- 6:31 PM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) closed by
- No Bug
- 4:53 PM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) updated by
- So you're reporting a bug in 3.3.0.0 released almost one year ago but you can't reproduce it in a newer beta released a month ago? And you didn't even test on the latest beta... where you would have found a real bug. Anyway, you do understand how the development process works, right? If it's fixed in a beta... you don't open a bug report to tell us it didn't work in a version previous to the beta. I'm leaving this open only until I test on Windows 7 to make sure you didn't just invert your test versions or something.
- 9:46 AM Ticket #1334 (dynamic include - rt embedding - Bug found?) updated by
- > In most cases it's not necessary to execute a second script in the same address > space as the parent script. Also, I'm not sure why you are mentioning COM as that > seems totally unrelated. you told something about "extension interface" - what is an extension interface ? The onliest extensions I know in AutoIt are COM-Objects. (http://www.autoitscript.com/autoit3/docs/intro/ComRef.htm). I guess then you really meant a more basic coding way. Do you have any link or information about this technique you meant? It seems very interesting and sounds very flexible! > I don't really call creating a proper design that is capable of serializing and > marshaling state information across process boundaries a "workaround". I call it > the way this stuff is done in situations like this... Yes, you're totally right, in 99% of all cases it seems the need of a workaround due to an improper design. I found a case within the 1% where it really makes sense. You don't have to struggle around with this. I have a solution, but just wanted you to understand why I just tried to provide you my idea for helping autoit keeping better and better. And you're also right that this is a narrow band of problems if I think about all the other solutions you can achieve with the help of AutoIt. I just wanted to "campain" a bit for my idea =) Please don't take it amiss. Thanks for the informative answer. We just have different points of view, and maybe there was a small missunderstanding. You sounds a bit like, but I didn't want to annoy you, did I ? Sorry for that. I read the WikiStart section about the bug reporting. It seems it was a problem within the structure in the framework. I got another solution keeping the timer tick on. Tried to reproduce in a proof of concept, but there it works. As soon as it appears in any constellation, I will inform you with reproducing code in a new issue. Sincerelly.
- 9:13 AM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) updated by
- Ups, small typo: read 'compiled' when you encounter 'compiler'. PS: 1337 lol
- 9:09 AM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) created by
- Just found a very weird issue while testing some menus I intend to use …
- 5:19 AM Ticket #1329 (GUICtrlCreatePic width=height=0.) updated by
- Then please delete the related section from the help file too, to won't use developers that "feature" in the future! Thanks!
- 4:20 AM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) updated by
- This ticket is referenced in revision: [5442]
- 4:13 AM Ticket #1326 (_GuiCtrlListView_DeleteItem does not handle control ID correctly) closed by
- No Bug: You should never destroy something AutoIt created with anything other than the specified function for destruction. To that end the Example2() in the documentation is actually doing something bad. Likewise, your suggestion is doing something bad. AutoIt will never free the internal resources for any items destroyed that way.
- 4:05 AM Ticket #1329 (GUICtrlCreatePic width=height=0.) closed by
- Wont Fix: I'm closing this as "Won't fix". It's definitely a bug but it's the exact sort of bug that reminds me why the current GUI implementation is absolute garbage and why it needs ripped out and written by somebody who knows what they are doing. I'm afraid you're going to have to live with this one for a very long time.
- 3:45 AM Ticket #1330 (_GUICtrlListView_CreateSolidBitMap() - the same as ...) closed by
- No Bug: It looks like it's a thin wrapper provided for convenience. I think it's fine the way it is.
- 3:43 AM Ticket #1325 (Date.au3: calls to _Date_Time_SetLocalTime($pSystemTime) are not ...) closed by
- Fixed: Fixed by revision [5440] in version: 3.3.1.7
- 12:20 AM Ticket #1333 (Some AUTOIT scripts does not work with SMS/SCCM) closed by
- No Bug: As a Administrator on SCCM I can say that all current versions work just fine. If you have a script expecting screens, they are not going to work. This should of been posted on the forum as question.
Dec 9, 2009:
- 9:03 PM Ticket #1335 (_ColorConvertRGBtoHSL incorrectly normalised to 240) closed by
- No Bug: What makes you think it's wrong? Because it's not. Go open MSPaint and try to type 300 into any of the Hue, Saturation or Luminance fields of the color picker and see what it does.
- 8:44 PM Ticket #1322 (ControlCommand with "GetSelected" used on ListView crashes the script) updated by
- This ticket is referenced in revision: [5439]
- 7:27 PM Ticket #1328 (StringFormat() does not produce right output in AutoIt v3.3.1.6 (beta)) closed by
- Fixed: Fixed by revision [5438] in version: 3.3.1.7
- 7:03 PM Ticket #1331 (Help example for _GuiCtrlDTP_SetSystemTimeEx uses wrong struct.) closed by
- Fixed: Fixed by revision [5437] in version: 3.3.1.7
- 6:55 PM Ticket #1317 (UDFs & DllStructCreate() & char/wchar --> Unicode/ANSI problem) updated by
- This ticket will be fixed as part of the work done for #1336.
- 6:55 PM Ticket #1336 (Remove UDF hard-coded buffer sizes.) updated by
-
Owner, Component changed
- 6:54 PM Ticket #1318 (UDFs char/wchar --> bad numbers of bytes for _MemRead()/_MemWrite()) updated by
- This ticket will be fixed as part of the work done for #1336.
- 6:54 PM Ticket #1336 (Remove UDF hard-coded buffer sizes.) created by
- Using hard-coded buffer sizes is horrible programming. This ticket is …
- 6:32 PM Ticket #1323 (Wrong size of some types in DllStructCreate()) closed by
- Fixed: Fixed by revision [5436] in version: 3.3.1.7
- 5:19 PM Ticket #1334 (dynamic include - rt embedding - Bug found?) updated by
- Replying to anonymous: > You should read - and try to understand the issue, instead of just rejecting it. Alright, I read it. And it's still rejected. > The idea is really innovative and would solve many many problems people struggle around with. Just have a look into your forum... It's not innovative. It's a convenience to solve a very narrow band of problems. > Change the runtime over COM objects ? Execute sub-code within this context over this object ? Comeon ! How should this work without AutoIt providing an appropriate COM interface ? E.g use COM scripting with js ? yeah, more and more components, more and more struggling. What about debugging that com objects ? In most cases it's not necessary to execute a second script in the same address space as the parent script. Also, I'm not sure why you are mentioning COM as that seems totally unrelated. > All that is not practical without navive AutoIt running code ! Your definition of "practical" and mine are apparently drastically different. You apparently think it's okay to implement very niche features to solve a narrow band of problems and a lack of such a feature makes something "impractical" to do otherwise. I, on the other hand, would just do it using the tools available and move on. > Nevermind - you'll decide what happens to your product by yourself. > There are workarounds for this, but these are "not for the masses" =) I don't really call creating a proper design that is capable of serializing and marshaling state information across process boundaries a "workaround". I call it the way this stuff is done in situations like this. You clearly have something along these lines already. If it's designed properly then it will be completely transparent or at least no less transparent than some magical silver bullet solution you expect us to introduce. > What about the "bug" with the timers ? Can you track this issue anyway of the rejection? Read the last two points of the General Notes section of WikiStart. In addition if you find yourself asking "is this a bug" then you shouldn't be on here on the issue tracker with your problem at all.
- 12:39 PM Ticket #1334 (dynamic include - rt embedding - Bug found?) updated by
- You should read - and try to understand the issue, instead of just rejecting it. The idea is really innovative and would solve many many problems people struggle around with. Just have a look into your forum... Change the runtime over COM objects ? Execute sub-code within this context over this object ? Comeon ! How should this work without AutoIt providing an appropriate COM interface ? E.g use COM scripting with js ? yeah, more and more components, more and more struggling. What about debugging that com objects ? All that is not practical without navive AutoIt running code ! Nevermind - you'll decide what happens to your product by yourself. There are workarounds for this, but these are "not for the masses" =) What about the "bug" with the timers ? Can you track this issue anyway of the rejection?
- 5:34 AM Ticket #1322 (ControlCommand with "GetSelected" used on ListView crashes the script) closed by
- Fixed: Fixed by revision [5435] in version: 3.3.1.7
- 5:01 AM Ticket #1321 (DllStruct Element Name Limits) closed by
- Fixed: Fixed by revision [5434] in version: 3.3.1.7
- 1:34 AM Ticket #1332 (Mod funktion wrong output) updated by
- This ticket is referenced in revision: [5433]
- 1:30 AM Ticket #1332 (Mod funktion wrong output) closed by
- Fixed: Fixed by revision [5432] in version: 3.3.1.7
Dec 8, 2009:
- 8:25 PM Ticket #1303 (script to replace the @ScriptLineNumbe) closed by
- Rejected: This isn't going to be added to Obfuscator because that doesn't belong in there. It is easy to write a script to preprocess the input script which will: - add all include files. (Got a script for this already available) - replaces all @ScriptLineNumber with something like Filename/Original line number. There will be some hurdles to take and it doesn't look like to OP is interested in investing time here to properly define the scope. My current suggestion is to write a POC first yourself to demonstrate what is wanted and post that in the examples forum. Jos
- 8:17 PM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) closed by
- Works For Me: closed as there is no reply and cannot replicate the issue. Jos
- 7:17 PM Ticket #1333 (Some AUTOIT scripts does not work with SMS/SCCM) updated by
-
Version changed
You must be able to provide a small script we can reproduce the issue with. Big scripts are not useful because it becomes a needle in a haystack trying to figure out exactly what the problem is. Likewise, scripts we can't run due to complex environment requirements are not helpful. By the way, you don't file a bug report against a beta version that's no longer available. The latest stable version (at the time of this writing) is 3.3.0.0. You also haven't mentioned if you have tried the latest beta (3.3.1.6). - 7:09 PM Ticket #1334 (dynamic include - rt embedding - Bug found?) closed by
- Rejected: Too long, didn't read. The title says it all. AutoIt is a compiled language, there is no place for "dynamic #include" in AutoIt. Also I suggest you learn the language a little bit better and you should be able to design your own extension interface using existing functionality.
- 6:12 PM Ticket #1335 (_ColorConvertRGBtoHSL incorrectly normalised to 240) created by
- At the end of the UDF, HSL values are multiplied by 240 for no reason. …
- 1:00 PM Ticket #1334 (dynamic include - rt embedding - Bug found?) updated by
-
Version changed
Automatic ticket cleanup. - 12:17 PM Ticket #1334 (dynamic include - rt embedding - Bug found?) created by
- How about the try to do dynamic includes like: #include $myFile[0] …
- 11:27 AM Ticket #1333 (Some AUTOIT scripts does not work with SMS/SCCM) updated by
- If you wish i can provide you with one of the EXE (which i have created to Automate installation of CIsco VPN Client) compiled using AUTOIT versioned later than 3.1.1.
- 11:21 AM Ticket #1333 (Some AUTOIT scripts does not work with SMS/SCCM) created by
- Some of the scripts created using AUTOIT versions later than 3.1.1 …
- 3:51 AM Ticket #1332 (Mod funktion wrong output) updated by
- I don't know that an add-on would really help the situation. Its kind of something that needs fixed internally and its something that we need to do as soon as possible.
- 2:26 AM Ticket #1332 (Mod funktion wrong output) updated by
- Replying to Valik: OK. Last thing: are there other _basic_ core function besides bitwise ops and Mod() having a 32-bit int or floating-point limitation right now, that could benefit of a 64-bit int add-on?
- 2:13 AM Ticket #1332 (Mod funktion wrong output) updated by
- I have changes made to do it as an int first and fall back onto floating point but I'm not sure at this time if that will be changed in the next release, at a later time or ever.
- 2:09 AM Ticket #1332 (Mod funktion wrong output) updated by
- Replying to Valik: > Yes, the problem is because the operation is being performed as floating point. Do you think it can get changed anytime soon or will it be part of a deeper rework to be expected significantly later? A workaround can be to code a small dll for 64-bit bitwise ops, Mod() and possibly other functions. Is it worth doing it, since it's very easy?
Dec 7, 2009:
- 11:29 PM Ticket #1332 (Mod funktion wrong output) updated by
- Yes, the problem is because the operation is being performed as floating point.
- 11:15 PM Ticket #1332 (Mod funktion wrong output) updated by
- Could it be a sign that Mod() in doing a floating-point computation instead of integral? Sounds like a 56-bit mantissa representation limitation. […]
- 5:43 PM Ticket #1332 (Mod funktion wrong output) created by
- mod("175367809538821201","1767842701") returns 421042353 but its wrong …
- 4:54 PM Ticket #1331 (Help example for _GuiCtrlDTP_SetSystemTimeEx uses wrong struct.) created by
- The 3.3.1.6 Beta include file StructureConstants.au3 no longer defines …
- 1:15 AM Ticket #1330 (_GUICtrlListView_CreateSolidBitMap() - the same as ...) created by
- _GUICtrlListView_CreateSolidBitMap in GUIListView.au3 include file is …
Note:
See TracTimeline
for information about the timeline view.
