Timeline
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 …
Dec 6, 2009:
- 10:08 PM Ticket #1329 (GUICtrlCreatePic width=height=0.) created by
- 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
- 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
- Fixed: Fixed by revision [5430] in version: 3.3.1.7
- 9:03 PM Ticket #1312 (_GUIImageList_BeginDrag.au3 - example in helpfile) closed by
- 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
- 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
- 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
- _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
- 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
- Rejected: Write your own.
- 9:00 PM Ticket #1324 (MsgBox: options for size and position) updated by
-
Version changed
Automatic ticket cleanup. - 8:01 PM Ticket #1324 (MsgBox: options for size and position) created by
- 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
- Documentation says that the size of 'ptr' with DllStructCreate() is 4 …
- 9:45 AM Ticket #851 (Compile Script - UPX.exe error) updated by
- 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
- 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
- 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
- To reproduce the bug, just open some Explorer window (folder), and run …
- 2:06 PM Ticket #1321 (DllStruct Element Name Limits) created by
- I couldn't find this any where in the documentation, but …
- 11:48 AM Ticket #1320 (_GUIImageList_DragMove() - bad hWnd parameter) created by
- 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
-
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_Destroyon 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_SetOLECallbackfrom 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
- this is a workaround working on xp: […]
- 5:03 PM Ticket #1319 (AutoIt3.exe always exists after closing script with RichEdit) updated by
- 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
- 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
- What exactly did you have in mind here? How should this work? Jos
- 11:39 AM Ticket #1284 (minor fold hickup.) updated by
- Updated SciLexer.DLL available in the Beta directory of the SciTE4AutoIt3 website. Jos
- 11:37 AM Ticket #1284 (minor fold hickup.) closed by
- 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
- >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
- 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
- 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
- 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
- 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
- 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
- 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
-
Version changed
Automatic ticket cleanup. - 10:56 PM Ticket #1316 (SleepUntilTime($hour, $min, $sec) and RunOnTime($hour, $min, $sec, ...) created by
- #include<Date.au3> ;Idea of first: Func SleepUntilTime($hour, $min, …
- 10:22 PM Ticket #1314 (ColorMode (Option) problem) created by
- 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
- 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
- @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
- 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
-
Version changed
Automatic ticket cleanup. - 6:02 PM Ticket #1313 (Add Opt.htm page redirecting to AutoItSetOption.htm) created by
- 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
- ad 2) The same applies also to another function: […]
- 9:18 AM Ticket #1312 (_GUIImageList_BeginDrag.au3 - example in helpfile) updated by
- 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
- "C:\Program …
Nov 26, 2009:
- 5:00 PM Ticket #1311 (MouseGetCursor() - identify also standard hand cursor (IDC_HAND)) updated by
-
Version changed
Automatic ticket cleanup. - 3:55 PM Ticket #1311 (MouseGetCursor() - identify also standard hand cursor (IDC_HAND)) created by
- I'm looking at sources of MouseGetCursor() in script_misc.cpp …
- 7:04 AM Ticket #1310 (TCPConnect Timeout) created by
- I'd like the TCPconnect() function to have a parameter where you can …
Nov 25, 2009:
- 8:39 AM Ticket #1309 (BitShift() as Unsigned Integer by Default) closed by
- Rejected: No. AutoIt needs to have better handling of unsigned integers in general. This will not be done on a function-by-function basis.
- 7:40 AM Ticket #1309 (BitShift() as Unsigned Integer by Default) created by
- Change AutoIt's default BitShift() behavior to peform the operation as …
- 12:09 AM Ticket #1308 (Execute to assign variable) updated by
- Nice. I'm excited for the new assign and eval features. Will make rewriting some of the array functions to support all different dimensions easier.
Nov 24, 2009:
- 11:19 PM Ticket #1308 (Execute to assign variable) closed by
- Rejected: One of these days Assign() and Eval() will support arrays. That makes this feature request redundant.
- 9:00 PM Ticket #1308 (Execute to assign variable) updated by
-
Version changed
Automatic ticket cleanup. - 8:18 PM Ticket #1308 (Execute to assign variable) created by
- It would be nice if the execute() function could assign variables. …
Nov 22, 2009:
- 10:40 PM Ticket #1307 (Better and consistent naming of boolean parameters in UDF functions) closed by
- Rejected: Code comes from more than one individual and we currently have no requirements on how it should be formatted. I'm closing this because it's an all or nothing thing. Either we review all code and ensure it conforms to a format we come up with, or we do nothing. At this point in time, we do nothing.
- 10:15 PM Ticket #1307 (Better and consistent naming of boolean parameters in UDF functions) created by
- I would like to request that a bit more consistent logic is used in …
- 7:37 PM Milestone 3.3.1.6 completed
- 6:05 PM Ticket #975 (GUICtrlCreateCheckbox() on tabs.) closed by
- Fixed: Fixed by revision [5418] in version: 3.3.1.6
- 5:12 PM Ticket #1153 (User-defined libraries support with 'Open Include'.) closed by
- Rejected
- 5:10 PM Ticket #1306 (DriveGetSerial Docs can be misleading) closed by
- Fixed: Fixed by revision [5417] in version: 3.3.1.6
- 5:03 PM Ticket #1296 (_GUICtrlTreeView_ClickItem fails with item text wider than TreeView) closed by
- Fixed: Fixed by revision [5416] in version: 3.3.1.6
- 4:56 PM Ticket #1290 (_GUICtrlTreeView_DisplayRectEx with "$fTextOnly = True" returns same ...) closed by
- Fixed: Fixed by revision [5415] in version: 3.3.1.6
- 3:22 AM Ticket #1306 (DriveGetSerial Docs can be misleading) created by
- This is not important at all because most of us know the answer but …
Nov 21, 2009:
- 12:56 PM Ticket #1294 (WinGetTitle freezes script when reading the title of a ...) closed by
- Fixed: Fixed by revision [5412] in version: 3.3.1.6
Nov 20, 2009:
- 6:47 AM Ticket #1305 (GUISetFont, GUICtrlCreateTreeViewItem, korean language combination bug) closed by
- No Bug: This is not a bug. The font you choose must contain Chinese and Korean characters in order for it to know what to render. Presumably the default font you have configured contains those characters. When you change to a different font that doesn't contain those characters... then the non-Latin characters can't be rendered.
- 6:14 AM Ticket #1305 (GUISetFont, GUICtrlCreateTreeViewItem, korean language combination bug) created by
- If you use the korean language with a treeview …
Nov 18, 2009:
- 5:27 PM Ticket #1279 (_FTP_FilePut() - DOC precission - for parametres) closed by
- Fixed: Fixed by revision [5406] in version: 3.3.1.6
- 5:06 PM Ticket #1304 (_GDIPlus_BitmapLockBits() input parameters are incorrect) closed by
- Fixed: Fixed by revision [5404] in version: 3.3.1.6
- 2:45 PM Ticket #1277 (_GDIPlus_ImageGetGraphicsContext needs to be "disposed" in help example) closed by
- Fixed: Fixed by revision [5402] in version: 3.3.1.6
- 2:39 PM Ticket #1291 (FileSetTime() Error descripton) closed by
- Completed: Added by revision [5401] in version: 3.3.1.6
- 11:42 AM Ticket #1304 (_GDIPlus_BitmapLockBits() input parameters are incorrect) created by
- […] According to the help file, $iRight and $iBottom refer to the …
- 4:25 AM Ticket #1283 (aut2exe_x64 Ignores /pack Parameter When Compiling x86 Executable) updated by
- Replying to Valik: > AutoItWrapper will need to be updated to support the new /x86 parameter and the re-addition of the /unicode parameter. Beyond that nothing needs done to AutoItWrapper. It is up to you properly pass the correct command line arguments (or set the appropriate AutoItWrapper flags when they are suppored) to force the binary output to what you want. That's what I meant, the current AutoIt3Wrapper flags won't allow for proper compilation. By default AutoIt3Wrapper builds x86 even on an x64 platform (maybe that should be changed to reflect the Aut2Exe default behavior and build x64 by default?). Now it will also need to pass the new parameters when the x86 bin is used (#AutoIt3Wrapper_UseX64=n).
Nov 17, 2009:
- 10:05 PM Ticket #1270 (GUISetIcon (@ScriptName) sets the 48x48 icon to the GUI) closed by
- Completed: Added by revision [5393] in version: 3.3.1.6
- 8:04 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) closed by
- Fixed: Fixed by revision [5392] in version: 3.3.1.6
- 8:00 PM Ticket #1270 (GUISetIcon (@ScriptName) sets the 48x48 icon to the GUI) updated by
-
Version changed
Automatic ticket cleanup. - 7:55 PM Ticket #1270 (GUISetIcon (@ScriptName) sets the 48x48 icon to the GUI) updated by
-
Type, Severity changed
Changing to a feature request. We need a complete overhaul of the icon loading code and it has to try different resolutions and depths depending on the OS. We also only support loading the "small" icon atm. So we would need to change that to both small and large. So not a simple change. - 5:09 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- This ticket is referenced in revision: [5391]
- 4:49 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- Lucky guess, Jon, though obvious. UNICODE length < ANSI length = boom. o.o
- 3:31 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- […] AutoIt3_x64-thesnow.exe it's worked too.
- 3:21 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- I'm not sure it's related but I fixed a typo in some conversion code. Can you test this version please: http://www.autoitscript.com/autoit3/files/beta/autoit/AutoIt3_x64-thesnow.exe
- 3:01 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- Can you try this please: […] Without that flag the write is written in ANSI using the codepage. I'm wondering if there's something wrong in the chinese unicode -> ansi conversion code. But need to rule out some things first.
- 10:00 AM Ticket #1303 (script to replace the @ScriptLineNumbe) updated by
-
Version changed
Automatic ticket cleanup. - 9:00 AM Ticket #1303 (script to replace the @ScriptLineNumbe) created by
- Add in the possibility of replacing SciTe @ScriptLineNumber on line …
- 9:00 AM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- System info: […]
- 8:49 AM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- […] it's work! […] […]
- 8:42 AM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- I have turn off all antivirus software. 3.3.0.0 is worked. 3.3.1.5 is Crashed. 3.3.1.3 is worked.
- 3:09 AM Ticket #1298 (Poor Behavious of UBound Function) updated by
- Actually, you're just plain wrong. Visual Basic and VBS both behave very much like AutoIt. If you need to track the last used index then track it yourself. AutoIt cannot do that for you. No language can do it with 100% reliability to suit everyone. AutoIt, VB and VBS all have the correct behavior which is to report what the highest possible index is (keeping in mind the index needs offset by subtracting 1).
- 2:54 AM Ticket #1257 (Fix bugs in Static array handling) updated by
-
Severity changed
- 2:54 AM Ticket #1265 (Au3Check support for Static) updated by
-
Severity changed
- 2:52 AM Ticket #975 (GUICtrlCreateCheckbox() on tabs.) updated by
-
Severity changed
- 2:51 AM Ticket #865 (winhttp.winhttprequest.5.1 ObjEvent unhandled exception.) updated by
-
Severity changed
- 2:51 AM Ticket #1294 (WinGetTitle freezes script when reading the title of a ...) updated by
-
Severity changed
- 2:49 AM Ticket #1298 (Poor Behavious of UBound Function) updated by
- Even I hate VB, I think VB behaves more logically correct. UBound should return the Upper Index of an array instead of Upper Index + 1, If you name UBound as ArraySize, then the current implementation is correct. I am interested to see other admin's comment
- 2:46 AM Ticket #1301 (Bug InetGetSize through a proxy) closed by
- No Bug: It works fine for me. I can clearly see the connection passing through the proxy (by looking at the proxy access log).
- 2:21 AM Ticket #1297 (wrong $bPasswordHash in the example of _Crypt_HashData-documentation, ...) closed by
- Fixed: Fixed by revision [5390] in version: 3.3.1.6
- 2:15 AM Ticket #1300 (DllCall() unloads the loaded module) closed by
- Fixed: Fixed by revision [5389] in version: 3.3.1.6
- 2:09 AM Ticket #1299 (AU3Check: #include with Single-Quote character, File not found.) closed by
- Fixed: Fixed by revision [5388] in version: 3.3.1.6
Nov 16, 2009:
- 10:36 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
-
Severity changed
- 10:31 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
-
Owner, Status changed
- 10:30 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- Did it also happen in the release version 3.3.0.0? Or is it just the beta?
- 10:27 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- Which part of the script is crashing for you? Can you make it smaller? What about just this: […]
- 10:11 PM Ticket #1295 (Crashed with fileread and filewrite on windows 7 X64) updated by
- I tried x86 and x64 on Windows 7 x64 and both worked ok for me. Maybe an Anti Virus related problem?
- 8:45 PM Ticket #1283 (aut2exe_x64 Ignores /pack Parameter When Compiling x86 Executable) updated by
- Replying to wraithdu: > However it sounds like Aut2Exe still thinks it's compiling x64, hence the ignored /pack parameter. A full fix would need some work by Jos in AutoIt3Wrapper to accomodate your changes I think. AutoItWrapper will need to be updated to support the new /x86 parameter and the re-addition of the /unicode parameter. Beyond that nothing needs done to AutoItWrapper. It is up to you properly pass the correct command line arguments (or set the appropriate AutoItWrapper flags when they are suppored) to force the binary output to what you want.
- 8:43 PM Ticket #1302 (InetGet - Multiple) closed by
- Completed: Maybe you should have looked at the beta? It's been available in the beta since May.
- 8:37 PM Ticket #1283 (aut2exe_x64 Ignores /pack Parameter When Compiling x86 Executable) updated by
- Replying to wraithdu: > I see. That would explain Jos's 'workaround' in AutoIt3Wrapper where he copies the desired .bin to a temp directory and feeds it to Aut2Exe via the /bin parameter. > The only reason I do this is to update the resource info in the copy of the BIN file before the aut2exe step. Doing that after the aut2exe step gave problems. Jos
- 8:00 PM Ticket #1283 (aut2exe_x64 Ignores /pack Parameter When Compiling x86 Executable) updated by
- I see. That would explain Jos's 'workaround' in AutoIt3Wrapper where he copies the desired .bin to a temp directory and feeds it to Aut2Exe via the /bin parameter. However it sounds like Aut2Exe still thinks it's compiling x64, hence the ignored /pack parameter. A full fix would need some work by Jos in AutoIt3Wrapper to accomodate your changes I think.
- 8:00 PM Ticket #1302 (InetGet - Multiple) updated by
-
Version changed
Automatic ticket cleanup. - 6:56 PM Ticket #1302 (InetGet - Multiple) created by
- Hello, Would it be possible to enable the use of 2 or more instances …
- 12:36 PM Ticket #1301 (Bug InetGetSize through a proxy) created by
- InetGetSize() with "username:password@" did not go through a proxy. …
Nov 15, 2009:
- 11:05 PM Ticket #1300 (DllCall() unloads the loaded module) created by
- There is a possible situation with freeing loaded modules that are …
- 5:38 PM Ticket #1298 (Poor Behavious of UBound Function) closed by
- Rejected: The behavior of VB is stupid.
- 4:49 PM Ticket #1299 (AU3Check: #include with Single-Quote character, File not found.) created by
- AU3Check (1.54.14.0) versus (1.54.19.0) AU3Check (1.54.19.0) can't …
- 4:00 PM Ticket #1298 (Poor Behavious of UBound Function) updated by
-
Version changed
Automatic ticket cleanup. - 2:53 PM Ticket #1298 (Poor Behavious of UBound Function) created by
- For UBound function, it gives me an impression that it should return …
- 2:16 AM Ticket #1009 (Remove hard-coded calls to ConsoleWrite() in SQLite.au3) reopened by
- 12:36 AM Ticket #1294 (WinGetTitle freezes script when reading the title of a ...) updated by
- After reading the above comment WinSetState is also affected, if trying to set the state of the window to something else than the current state (that is, trying to change the state of the targeted suspended window). I forgot to mention my testing where done with : WinXP SP3 and AutoIT 3.3.0.0
Nov 14, 2009:
- 10:13 PM Ticket #1297 (wrong $bPasswordHash in the example of _Crypt_HashData-documentation, ...) updated by
- sorry, the version is not 3.3.0.0. The version is 3.3.1.5
- 10:11 PM Ticket #1297 (wrong $bPasswordHash in the example of _Crypt_HashData-documentation, ...) created by
- Hello, the $bPasswordHash in the example of the …
- 6:14 PM Ticket #975 (GUICtrlCreateCheckbox() on tabs.) updated by
- Replying to Valik: > Undoubtedly a regression caused by the "fix" for #1087. Most probably indeed. Sorry I missed the link to this later one.
- 4:23 PM Ticket #975 (GUICtrlCreateCheckbox() on tabs.) reopened by
- Undoubtedly a regression caused by the "fix" for #1087.
- 1:34 AM Ticket #975 (GUICtrlCreateCheckbox() on tabs.) updated by
- Bug reappeared in 3.3.1.4 and 3.3.1.5 (OS:WIN_XP/Service Pack 3 CPU:X86). Here's another script to demo: run from Scite or compile. MessageBox says it all. […]
Nov 13, 2009:
- 11:51 PM Ticket #1294 (WinGetTitle freezes script when reading the title of a ...) updated by
- Just as a reminder here; this is an old issue that has been talked about in the forum atleast once. See topic 97196 http://www.autoitscript.com/forum/index.php?showtopic=97196
Note:
See TracTimeline
for information about the timeline view.
