AutoIt v3.3.9.21 Beta

[Jon]

File Name: AutoIt v3.3.9.21 Beta

File Submitter: Jon

File Submitted: 11 Sep 2013

File Category: Beta

3.3.9.21 (11th September, 2013) (Beta)
AutoIt:
- Added #2443: Monospaced in Fonts appendix.

- Changed: Documentation for StringRegExp() re-written by jchd.
- Changed: Default newline character for PCRE regexes changed to ANYCRLF.

- Fixed #2066: DllStructSetData() returning int64 instead of int32 in some cases.
- Fixed #2427: ControlTreeView() does not used Option2.
- Fixed #2455: Mouse Cursor not changing on resizable GUIs.
- Fixed #2105: RegRead() and DWORD types incorrectly stored as double.
- Fixed #2299: GUI Button Text Left-Justify for colored button.
- Fixed #1954: ListViewItem returns 0 (failure) even though it populates the ListView.
- Fixed #2152: X^2 Not Working in Hex().
- Fixed #1870: @GUI_DRAGFILE.

Click here to download this file

[UEZ]

You forgot:

-Added some more GDI+ functions and examples.

Br,

UEZ 

[FireFox]

  On 9/11/2013 at 9:43 AM, UEZ said:

You forgot

No, my fault Edited September 11, 2013 by FireFox

[trancexx]

I see there have been some workings on X^2 problematic.

Can someone give short explanation on why is this treated as integer:

$nNum =  2.0 ^ 1

... and this as double:

$nNum =  2.0

Thanks in advance.

[Mat]

TranceXX, more importantly that introduces a regression on certain values for the exponent.

I suspect the code looks something like if (exp % 1 == 0) { /* Cast return value to int */ }

That gives the wrong result when the exponent is negative, for example 2^-1 should give 0.5 but is being truncated to zero.

[trancexx]

Maybe someone should open bug report named "X/2 not working in Hex".

The problem is not Hex(), the problem is not even on the level that Jon tried to fix it. It's below that. Fixing it above that can only produce new bugs.

Bug report that was referenced was, and is, senseless in its essence.

[rdr]

Hello,

Is there any plan on when this version will become official?

Thank you!

[Melba23]

rdr,

As always, there will be a release when Jon thinks it is ready.

M23

[Mat]

I'm not sure why Hex() was ever changed from using only integers to be honest. The few people who know what the output means could easily do it in about 4 lines anyway. 

Jon, The only time the output should be converted to an integer is if: Both operands are integral and the exponent is positive. That's basically what TranceXX is saying here.

Edited September 11, 2013 by Mat

[Jon]

Hex wasn't touched. The code changed was at the low level and is something JP said he'd verified. The code "looks" right in that it does indeed check for integers but it turns out some code that determines the integer status is also flawed.

[trancexx]

  On 9/11/2013 at 11:07 AM, Mat said:

I'm not sure why Hex() was ever changed from using only integers to be honest. The few people who know what the output means could easily do it in about 4 lines anyway.

That can be said for half of the built-in functions - 2, 3, 4, 5, 10 lines of script code from people who know. Your argument isn't right.

Hex was "changed" because it didn't do what it was said it should do. Hex(2.1) is not 0002.

Do you understand now?

...What I should have done back then was add new function Hex2() and remove documentation for Hex(). And fight another war.

[Mat]

  On 9/11/2013 at 11:36 AM, trancexx said:

That can be said for half of the built-in functions - 2, 3, 4, 5, 10 lines of script code from people who know. Your argument isn't right.

Hex was "changed" because it didn't do what it was said it should do. Hex(2.1) is not 0002.

Do you understand now?

...What I should have done back then was add new function Hex2() and remove documentation for Hex(). And fight another war.

Yes, but the difference is the people that don't know. The built in functions make the language simple.

Why couldn't Hex() say in the docs that it only takes integers as input? Quick docs change and everyone is happy.

Besides, I think Hex(2.1) should return 2.19999...., that's the correct answer.

[trancexx]

  On 9/11/2013 at 11:45 AM, Mat said:

Yes, but the difference is the people that don't know. The built in functions make the language simple.

Uhm, that's what I said.

  Quote

Why couldn't Hex() say in the docs that it only takes integers as input? Quick docs change and everyone is happy.

 

Besides, I think Hex(2.1) should return 2.19999...., that's the correct answer.

Excellent point. Not.

Because that was never the case, because it doesn't make sense, because it can take strings, because of your first sentence, because because because. It was a bug, nothing more.

[Mat]

Hex() can't take strings. It can take integers passed as strings. When last I checked Hex("TEST") doesn't return 0x54455354. Actually wait, that's a bug right?

The Hex() function is now overcomplicated. There is functionality which will never be used, and instead just confuses people. All so it could be "right". 

[jpm]

@trancexx

I will look why 2.0 is considered as an integer when used with pow operator.

I suspect that it is the same why Autoit display 2 and not  2.0 with ConsoleWrite(2.0 & @CRLF)

[trancexx]

@Mat, not integers but numbers.

Try binary data.

 

  On 9/11/2013 at 12:40 PM, Mat said:

The Hex() function is now overcomplicated. There is functionality which will never be used, and instead just confuses people.

That's why I said Hex2(). Edited September 11, 2013 by trancexx

[Tlem]

  On 9/11/2013 at 8:07 AM, Jon said:

- Added #2443: Monospaced in Fonts appendix.

 

Wrong track number. It's #2433.

[jpm]

  On 9/11/2013 at 10:19 PM, Tlem said:

Wrong track number. It's #2433.

Thanks, Fixed

[Mauris]

Goodbye AutoIt, goodbye community, thank Jon, Valik, Gary Frost, Jos and trancexx, version 3.3.8.1 the best.

[jaberwacky]

lol

This actually made me giggle.

Wow.  Passive aggressive much?

You said goodbye to the community on your first post!

Edited September 12, 2013 by jaberwocky6669