Context Navigation

← Previous Period
Next Period →

Timeline

Dec 27, 2009:

11:50 PM Ticket #384 (More extensive testing of RunAs()) updated by Valik: This ticket is referenced in revision: [5482]
11:14 PM Ticket #384 (More extensive testing of RunAs()) updated by Valik: 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 Valik: Fixed: Fixed by revision [5480] in version: 3.3.3.0
8:34 PM Ticket #1372 (HTTPSetUserAgent bad description) created by Greek: Help file only says that it works with InetGet() But it works with …
6:20 PM Ticket #1371 (_TempFile() update) updated by Valik: There is no need for the code to explicitly test -1.
6:00 PM Ticket #1371 (_TempFile() update) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
5:41 PM Ticket #1371 (_TempFile() update) created by xrewndel <xrewndel@…>: Add this in _TempFile() to accept "Default" keyword or -1 value […]
5:19 PM Ticket #1369 (Static.au3 example not working) closed by Valik: 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 anonymous: […]
3:02 PM Ticket #1369 (Static.au3 example not working) created by JamesBrooks: 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 Valik: 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 Valik: 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 Valik: 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 eukalyptus: this code workes fine on AutoIt 3.3.0.0, but returns zero (no …
6:19 PM prova.au3 attached to Ticket #1367 by isolation@…: GUIDelete crashes the executable
6:18 PM Ticket #1367 (GUIDelete() crashes program when called from WM_* message handler) created by isolation@…: GUIDelete() crashes the autoit compiled executable and also the …
4:08 PM Ticket #1366 (TrayCreateItem() bug) created by anonymous: TrayCreateItem(text [, menuID [, menuentry [, menuradioitem]]]) works …
12:48 PM Bild6.png attached to Ticket #1365 by Mulder: a screenshot of the GUI on w2k and Xp
12:47 PM Ticket #1365 (Windows 2000: GUICtrlCreateLabel before GUICtrlCreateCombo prevent ...) created by Mulder: 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 Valik: Duplicate: No shit? I guess #15 isn't good enough?
8:00 PM Ticket #1364 (IniReadSection update) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
6:09 PM Ticket #1364 (IniReadSection update) created by xrewndel <xrewndel@…>: IniReadSection ( "filename", "section" ) Only the first 32767 chars …
5:58 PM Ticket #1363 (FileSetPos() error) created by xrewndel: FileSetPos($hFile, $num, $FILE_CURRENT) works incorrectly. Result is …

Dec 24, 2009:

5:23 AM Ticket #1362 (_WinAPI_WindowFromPoint() broken on x64) updated by Ultima: 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 Ultima: 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 Valik: Rejected
7:55 PM Ticket #1361 (_SetTime() and _SetDate() crash when accessing non-array) created by gtyler: Here's the trace: […] I suggest changing two lines of code: 2245: …
6:55 PM error.jpg attached to Ticket #1360 by Tweaky: 2 lines
6:55 PM Ticket #1360 (for what are these files) created by Tweaky: 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 Miraged: 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 Jos: Why not simply use FileInstall() ? Jos
8:22 PM Ticket #1359 (Embed a file in compiled script) created by flackrobert@…: 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 Valik: 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 Jos: 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 TicketCleanup: Milestone changed
Automatic ticket cleanup.
4:34 PM Ticket #1344 (_WinAPI_CreateFile - Use of magic number and resulting 64-bit ...) closed by J-Paul Mesnage: Fixed
2:11 PM Ticket #1325 (Date.au3: calls to _Date_Time_SetLocalTime($pSystemTime) are not ...) updated by gtyler: 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 Miraged: 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 J-Paul Mesnage: 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 anonym: In section "Examples" of FileCreateNTFSLink are parameters "source", …
9:50 PM Ticket #1357 (New concatenation operator for Static) updated by trancexx: 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 Valik: 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 Valik: 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 trancexx: 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 anonymous: 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 jchd: 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:59 PM Fcdup.png attached to Ticket #1356 by Matt Diesel: Screenshot to show problem with table
9:58 PM Ticket #1356 (Problem with table data for _GDIPlus_GraphicsMeasureString) created by Matt Diesel: 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 J-Paul Mesnage: 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 Valik: Ugh.
2:07 PM Ticket #15 (Rewrite INI functionality to remove limitations.) updated by PsaltyDS: 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 anonymous: 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 Valik: 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 trancexx: 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 MrCreatoR <mscreator@…>: >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 J-Paul Mesnage: I cannot reproduce your pb under XP/SP2 see attach file
9:31 AM #1352 XP.JPG attached to Ticket #1352 by J-Paul Mesnage
8:54 AM Ticket #1338 (_arrayDisplay() GUI position error) closed by J-Paul Mesnage: Fixed: Fixed by revision [5465] in version: 3.3.3.0
8:07 AM Ticket #1354 (sqlite function problem...) updated by Valik: Do you honestly think this is the correct way to submit a bug report?
7:49 AM Ticket #1354 (sqlite function problem...) created by anonymous111: 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 PsaltyDS: Reported by user anixon: …
8:34 PM Ticket #1352 (StringSplit hard crash on binary data) created by MrCreatoR <mscreator@…>: 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 J-Paul Mesnage: Owner, Status changed
6:06 PM Ticket #1346 (Send doesn't work with windows opened under another user) updated by 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.
1:55 PM Ticket #1346 (Send doesn't work with windows opened under another user) updated by anonymous: 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 Jos: No Bug: Use the forum to ask questions.
8:46 PM Ticket #1351 (Why "text" = 0 ?) created by anonymous: Environment = 3.3.0.0 under WIN_XP/Dodatek Service Pack 2 X86 […] …
6:27 PM Ticket #1350 (Obfuscator line excludes) closed by Jos: Rejected: This is implemented already. […] Ask support via the forum.
5:37 PM Ticket #1349 (InetGet not working without Filename) closed by Valik: 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 TicketCleanup: Version changed
Automatic ticket cleanup.
4:41 PM Ticket #1350 (Obfuscator line excludes) updated by anonymous: #Obfuscator_Ignore_Variables not working
3:33 PM Ticket #1350 (Obfuscator line excludes) created by sbrown@…: 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 wraithdu: 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 Gismo_0307@…: There is no network communication for InetGet if the optional …
9:34 AM Ticket #1348 (aut2exe Mangles Named RCDATA Resources) updated by Zedna: 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 wraithdu: 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 Valik: 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 anonymous: >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 Jos: 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 Valik: And you are referring to what specifically?
7:26 PM Ticket #1347 (Restoring cursor position after certain scite4autoit tools.) created by anonymous: 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 Valik: 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 Valik: 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 Valik: 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 podws@…: 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 MeJonah@…: As the summary says, Number() used on a string that contains a number …
2:38 PM WinAPI_Modified.zip attached to Ticket #1344 by Miraged: Zip file containing modified version of WinAPI.au3
2:36 PM Ticket #1344 (_WinAPI_CreateFile - Use of magic number and resulting 64-bit ...) created by Miraged: 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 GEOSoft: 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 Valik: 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 thomas.baglin@…: $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 anonymous: Script here: Dim $total WinWaitActive("Progress Quest - New …
9:53 PM Ticket #1340 (Send("{ENTER}") in IE7) created by jeromeys@…: 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 Valik: 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 Valik: 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 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?). 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 Jos: 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 wraithdu: 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 anonymous: 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 Valik: 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 Valik: 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 autoit-trac@…: http://autoit.de/hilfe for recent German files. Thanks for adding!
10:35 PM Ticket #1335 (_ColorConvertRGBtoHSL incorrectly normalised to 240) updated by QED: 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 Bowmore: 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 danielkza2@…: 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 Xenobiologist: Hi, if there is some time available, these links should be updated. …
8:22 PM Ticket #1338 (_arrayDisplay() GUI position error) created by Bowmore: 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 Valik: No Bug
4:53 PM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) updated by Valik: 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 anonymous: > 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 danielkza2@…: Ups, small typo: read 'compiled' when you encounter 'compiler'. PS: 1337 lol
9:11 AM _GUICtrlMenu_CreatePopup.au3 attached to Ticket #1337 by danielkza2@…: _GUICtrlMenu_CreatePopup Example
9:09 AM Ticket #1337 (Custom context (popup) menus not working on non-compiled script) created by danielkza2@…: 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 anonymous: 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 Valik: This ticket is referenced in revision: [5442]
4:13 AM Ticket #1326 (_GuiCtrlListView_DeleteItem does not handle control ID correctly) closed by Valik: 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 Valik: 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 Valik: 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 Valik: 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 Gary: 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 Valik: 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 Valik: 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 Jon: 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 Valik: 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 Valik: 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 Valik: Owner, Component changed
6:54 PM Ticket #1318 (UDFs char/wchar --> bad numbers of bytes for _MemRead()/_MemWrite()) updated by Valik: 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 Valik: 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 Valik: Fixed: Fixed by revision [5436] in version: 3.3.1.7
5:19 PM Ticket #1334 (dynamic include - rt embedding - Bug found?) updated by Valik: 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 anonymous: 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 Valik: Fixed: Fixed by revision [5435] in version: 3.3.1.7
5:01 AM Ticket #1321 (DllStruct Element Name Limits) closed by Valik: Fixed: Fixed by revision [5434] in version: 3.3.1.7
1:34 AM Ticket #1332 (Mod funktion wrong output) updated by Valik: This ticket is referenced in revision: [5433]
1:30 AM Ticket #1332 (Mod funktion wrong output) closed by Valik: 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 Jos: 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 Jos: 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 Valik: 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 Valik: 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 QED: 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 TicketCleanup: Version changed
Automatic ticket cleanup.
12:17 PM Ticket #1334 (dynamic include - rt embedding - Bug found?) created by benjamin-thomas.schreiber@…: 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 anonymous: 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 sudheer_bangera@…: Some of the scripts created using AUTOIT versions later than 3.1.1 …
3:51 AM Ticket #1332 (Mod funktion wrong output) updated by Valik: 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 anonymous: 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 Valik: 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 anonymous: 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 Valik: Yes, the problem is because the operation is being performed as floating point.
11:15 PM Ticket #1332 (Mod funktion wrong output) updated by jchd: 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 Nike: mod("175367809538821201","1767842701") returns 421042353 but its wrong …
4:54 PM Ticket #1331 (Help example for _GuiCtrlDTP_SetSystemTimeEx uses wrong struct.) created by martin: 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 Zedna: _GUICtrlListView_CreateSolidBitMap in GUIListView.au3 include file is …

Dec 6, 2009:

10:08 PM Ticket #1329 (GUICtrlCreatePic width=height=0.) created by anonymous: If minimize and restore GUI, with using GUICtrlCreatePic with …
2:24 PM Ticket #1328 (StringFormat() does not produce right output in AutoIt v3.3.1.6 (beta)) created by realMo: There appears to be a bug in the StringFormat() function in the …

Dec 4, 2009:

9:07 PM Ticket #1320 (_GUIImageList_DragMove() - bad hWnd parameter) closed by Valik: Fixed: Fixed by revision [5430] in version: 3.3.1.7
9:03 PM Ticket #1312 (_GUIImageList_BeginDrag.au3 - example in helpfile) closed by Valik: Fixed: Fixed by revision [5429] in version: 3.3.1.7

Dec 3, 2009:

8:38 PM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) updated by Jos: Works for me. How did you test this?
8:27 PM Ticket #1327 (F1 in Scite Does Not Open Help File for Some Keywords) created by wraithdu: For some keywords, the help file is not opened via F1 in Scite (with …
8:34 AM Ticket #1326 (_GuiCtrlListView_DeleteItem does not handle control ID correctly) created by martin: _GuiCtrlListView_DeleteItem works if the listview handle is passed but …

Dec 2, 2009:

11:24 PM Ticket #1325 (Date.au3: calls to _Date_Time_SetLocalTime($pSystemTime) are not ...) created by gtyler: In Date.au3, there are several function that call …

Dec 1, 2009:

9:55 PM Ticket #1324 (MsgBox: options for size and position) closed by Valik: Rejected: Write your own.
9:00 PM Ticket #1324 (MsgBox: options for size and position) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
8:01 PM Ticket #1324 (MsgBox: options for size and position) created by hessebou: It would be nice if normal MsgBox also could be resized and positioned …
12:34 PM Ticket #1323 (Wrong size of some types in DllStructCreate()) created by trancexx: Documentation says that the size of 'ptr' with DllStructCreate() is 4 …
9:45 AM Ticket #851 (Compile Script - UPX.exe error) updated by anonymous: Correction: Not the au3 script name or build exe filename need to have a space in there names, but the path that is used to the (probebly) exe file.
8:58 AM Ticket #851 (Compile Script - UPX.exe error) updated by anonymous: Exe build, Upx lockup case. When the target output executeble, thats going to be build, is selected within a windows explorer window. In general upx part will fail with: Error: Unable to execute upx.exe to compress stub file: upx: C:\...\Script.exe: IOException: rename error: Permission denied In General, as building a exe with final(3.3.0.0) instead of beta(3.3.1.?), and if the source script has a space in its name. Its seems to be able to initally bybass this lockup error on the first consecutive build. In this case it seems to lockup in general on second consecutive build. AutoIt:3.3.1.6 (Os:WIN_XP/X86/Service Pack 3 Language:0409 Keyboard:00000409 Cpu:X86)
7:29 AM Ticket #1303 (script to replace the @ScriptLineNumbe) updated by anonymous: Not sure what Odin has in mind. But giving it a little thought, Obfuscator seems a nice candidate for a possible optional option for this. Thinking of the scanning of the original source files part, while merging them into one single file. As at this point it has access to the original(#include) line number's where the @ScriptLineNumber is used on.

Nov 30, 2009:

6:50 PM Ticket #1322 (ControlCommand with "GetSelected" used on ListView crashes the script) created by MrCreatoR <mscreator@…>: To reproduce the bug, just open some Explorer window (folder), and run …
2:06 PM Ticket #1321 (DllStruct Element Name Limits) created by mleo2003@…: I couldn't find this any where in the documentation, but …
11:48 AM Ticket #1320 (_GUIImageList_DragMove() - bad hWnd parameter) created by Zedna: In documentation there is mentioned bad (not existent) hWnd parameter: …

Nov 29, 2009:

5:38 PM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) updated by ProgAndy: Found the error: I think it is __GCR_SetOLECallback($hRichEdit) wich is called in _GUICtrlRichEdit_Create. When AutoIt is being closed, the callbacks or the dllstructs are freed before the RichEdit was destroyed. The Richedit tries to call the release function of the "object", but since it does not exist anymore, this leads to unexpected behaviour. It should be documented that you have to use _GUICtrlRichEdit_Destroy on exit. Also, the COM-Object should not be initialised for each richedit. Sometimes a RichEdit without image-support is needed. I propose to remove __GCR_SetOLECallback from the create function and document instead that you have to call an other function for image support.
5:09 PM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) updated by ProgAndy: this is a workaround working on xp: […]
5:03 PM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) updated by anonymous: Nearly the same on Windows 7. But on seven the Script just fatal exit: !>17:57:55 AutoIT3.exe ended.rc:-1073741819 No CPU load.
4:56 PM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) created by BugFix: Hi, i've used in SciTE the following script with Windows XP Home SP2. …
2:07 PM Ticket #1303 (script to replace the @ScriptLineNumbe) updated by Jos: What exactly did you have in mind here? How should this work? Jos
11:39 AM Ticket #1284 (minor fold hickup.) updated by Jos: Updated SciLexer.DLL available in the Beta directory of the SciTE4AutoIt3 website. Jos
11:37 AM Ticket #1284 (minor fold hickup.) closed by Jos: Fixed: Fixed by revision [5426] in version: 3.3.1.7

Nov 28, 2009:

9:40 PM Ticket #1313 (Add Opt.htm page redirecting to AutoItSetOption.htm) updated by MrCreatoR <mscreator@…>: >The documentation is auto-generated But it's could generate that page as well, or i missing something? Ok, then i think this should be at least fixed in the geshi... changes for autoit.php: 1) Remove 'Opt' from "3 => array(" list. 2) Replace in that same array this: […] with this: […] 3) Now replace this (styles): […] with this: […] 4) And now add to URLs array the 7-th element for the Opt link: […] P.S This fix i made on our AutoIt Russian Community forum, working well, but i just thought that this is can be fixed on the online documentation side.
8:38 PM Ticket #1318 (UDFs char/wchar --> bad numbers of bytes for _MemRead()/_MemWrite()) created by Zedna: According to Ticket #1317 there is similar ANSI/Unicode problem also …
7:41 PM Ticket #1317 (UDFs & DllStructCreate() & char/wchar --> Unicode/ANSI problem) created by Zedna: In latest Autoit version should be used in almost all UDFs wchar …
1:49 PM Ticket #1312 (_GUIImageList_BeginDrag.au3 - example in helpfile) updated by Zedna: ad 3) Purpose of that change is to have vertical scrollbar visible in listview (set less hight of listview) to be able to test implemented "autoscrolling" while draging functionality. BTW: That autoscrolling works very nice.

Nov 27, 2009:

11:42 PM Ticket #1314 (ColorMode (Option) problem) updated by andref: Sorry, my mistake. I'll be checking the latest version in the future.
11:22 PM Ticket #1316 (SleepUntilTime($hour, $min, $sec) and RunOnTime($hour, $min, $sec, ...) closed by Valik: Rejected: The first one is too trivial and the second one will not work. It seems you didn't notice AutoIt isn't multi-threaded.
11:20 PM Ticket #1314 (ColorMode (Option) problem) closed by Valik: No Bug: Congratulations on filing a completely useless bug report... twice. I really don't know how to chasten you further because you filed the report against 3.3.0.0 which implies you didn't bother to test with the latest beta like you should have. If you are testing with the latest beta but are for some reason reading the 3.3.0.0 documentation then you should read the changelog for the beta where you will discover the mode has finally been removed after languishing in a deprecated state for years.
11:00 PM Ticket #1316 (SleepUntilTime($hour, $min, $sec) and RunOnTime($hour, $min, $sec, ...) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
10:56 PM Ticket #1316 (SleepUntilTime($hour, $min, $sec) and RunOnTime($hour, $min, $sec, ...) created by andref: #include<Date.au3> ;Idea of first: Func SleepUntilTime($hour, $min, …
10:22 PM Ticket #1314 (ColorMode (Option) problem) created by andref: In AutoIT Help: ColorMode(Option)is sugested in PixelGetColor and …
9:50 PM Ticket #1313 (Add Opt.htm page redirecting to AutoItSetOption.htm) closed by Valik: Wont Fix: The documentation is auto-generated. The next time the online documentation is updated the change would be obliterated. This seems so minor as to not be worth fooling with.
9:10 PM Ticket #1311 (MouseGetCursor() - identify also standard hand cursor (IDC_HAND)) updated by Zedna: @MrCreatoR No. I want special non zero number for standard HAND cursor. Zero is returned for all other non standard (custom) cursors. So in this way we can distinguish standard ones. HAND cursor is the only one from all standard cursors not recoginzed by MouseGetCursor().
7:32 PM Ticket #1311 (MouseGetCursor() - identify also standard hand cursor (IDC_HAND)) updated by MrCreatoR <mscreator@…>: http://www.autoitscript.com/autoit3/docs/functions/MouseGetCursor.htm >Returns a cursor ID Number: 0 = UNKNOWN (this includes pointing and grabbing hand icons) 1 = APPSTARTING 2 = ARROW 3 = CROSS 4 = HELP 5 = IBEAM 6 = ICON 7 = NO 8 = SIZE 9 = SIZEALL 10 = SIZENESW 11 = SIZENS 12 = SIZENWSE 13 = SIZEWE 14 = UPARROW 15 = WAIT Perhaps 0 is the same?
7:00 PM Ticket #1313 (Add Opt.htm page redirecting to AutoItSetOption.htm) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
6:02 PM Ticket #1313 (Add Opt.htm page redirecting to AutoItSetOption.htm) created by MrCreatoR <mscreator@…>: This issue is more related to autoit tag on the forum... The …
9:23 AM Ticket #1312 (_GUIImageList_BeginDrag.au3 - example in helpfile) updated by Zedna: ad 2) The same applies also to another function: […]
9:18 AM Ticket #1312 (_GUIImageList_BeginDrag.au3 - example in helpfile) updated by Zedna: ad 2) I found this bug: […] There should be wchar instead of char: […] I think this kind of ANSI/Unicode bug probably will be also in another standard UDFs.
9:07 AM Ticket #1312 (_GUIImageList_BeginDrag.au3 - example in helpfile) created by Zedna: "C:\Program …

Note: See TracTimeline for information about the timeline view.

Download in other formats:

RSS Feed