Latest Beta

[ptrex]

I am very happy with this Fixed #983: InetGet() crash with IE6 !!

Thanks a lot for the quick fix.

ptrex

[GEOSoft]

Thanks Devs for the quick fixes.

Now onto another matter

_StringAddThousandsSep() has been removed from the UDFs with just cause. I have made it available on my site in the Stringx.au3 UDF at http://dundats.mvps.org/AutoIt/udf_code.aspx?udf=stringx but let me be very clear on one point.

Requests for changes will not even be responded to so don't bother asking. If it doesn't work like you want it to then write your own damn function to do it. That's it, that's all.

Edit: The function used is the same one that was in AutoIt-v3.3.1.0

Edited June 14, 2009 by GEOSoft

[James]

Nice lot of improvements there, well done guys!

[BaKaMu]

3.3.1.0 (20th May, 2009) (Beta)

AutoIt:

- Fixed #931: bad GUICtrlSetResizing() for graphic control. (Thanks martin)

Hi Jon,

-- Concerns to AutoIt3 V3.3.1.0 and 3.3.1.1

Bad GUICtrlSetResizing() for graphic control is not really fixed (only half the way) ;-)

Example:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <StaticConstants.au3>

Opt("GUIResizeMode", $GUI_DOCKALL)

$GUI_Main = GUICreate("Test Form", 410, 240, -1, -1, BitOR($WS_MINIMIZEBOX, $WS_SIZEBOX, $WS_THICKFRAME, $WS_SYSMENU, $WS_POPUP, $WS_GROUP, $WS_CLIPSIBLINGS), BitOR($WS_EX_TOOLWINDOW, $WS_EX_WINDOWEDGE, $WS_EX_TOPMOST)) ;no Titlebar, Dialog Border
GUISetBkColor(0x202020)

;GUIResizeMode = $GUI_DOCKALL, nevertheless graphics are moving  !!!
$picBg00 = GUICtrlCreateGraphic(4, 35, 200, 200)
GUICtrlSetColor(-1, 0xC0C0C0)
GUICtrlSetBkColor(-1, 0x30D030)
GUICtrlSetState(-1, $GUI_DISABLE)
;~ GUICtrlSetResizing(-1, $GUI_DOCKALL)  ;Workaround
;-----
$picBg01 = GUICtrlCreateGraphic(205, 35, 200, 200)
GUICtrlSetColor(-1, 0xC0C0C0)
GUICtrlSetBkColor(-1, 0xD03030)
GUICtrlSetState(-1, $GUI_DISABLE)
;~ GUICtrlSetResizing(-1, $GUI_DOCKALL)  ;Workaround
;-----
$lbl00 = GUICtrlCreateLabel("BgLabel 1", 4, 4, 200, 26, $SS_CENTER)
GUICtrlSetFont(-1, 17, 800, 0, "Arial")
GUICtrlSetBkColor(-1, 0xFFFFA0)
$lbl01 = GUICtrlCreateLabel("BgLabel 2", 205, 4, 200, 26, $SS_CENTER)
GUICtrlSetFont(-1, 17, 800, 0, "Arial")
GUICtrlSetBkColor(-1, 0xFFFFA0)
;-----
$cmd00 = GUICtrlCreateButton("Btn1", 74, 80, 60, 60, 0)
GUICtrlSetFont(-1, 10, 800, 0, "Arial")
$cmd01 = GUICtrlCreateButton("Btn2", 274, 80, 60, 60, 0)
GUICtrlSetFont(-1, 10, 800, 0, "Arial")
;-----
GUISetState(@SW_SHOW)

While 1
  $msg = GUIGetMsg()
    Switch $msg
      Case $GUI_EVENT_CLOSE
        ExitLoop ;Beenden
    EndSwitch
  Sleep(10)
WEnd

If you resize the GUI both graphics (green and red) are moving, even though the should not because Opt("GUIResizeMode", $GUI_DOCKALL).

Nevertheless i like the new beta cause the new Adlib and OnAutoItStart/OnAutoItExit features are very usefull functions.

You have done an excellent job, thank you for that.

BaKaMu

[jchd]

Hi everyone,

Thank you for this new beta.

Just a thought: wouldn't it be more natural and logical to invoke the OnAutoItExitRegister-ed functions in the reverse order of their registration, just like in any stack?

In this case, what should be the place of OnAutoItExit() itself, if defined? I would vote for placing it last, i.e. invoke it first. In my view this function would be ideal to deal with general fatal error with information of the user, then proceed to "layered shutdown" by unstacking each OnAutoItExitRegister-ed function(s) in turn.

What do you think?

[Valik]

Just a thought: wouldn't it be more natural and logical to invoke the OnAutoItExitRegister-ed functions in the reverse order of their registration, just like in any stack?

Yes. Yes it would. Should have been done that way from the start... but that's why we have betas.

In this case, what should be the place of OnAutoItExit() itself, if defined?

It should be invoked last (registered first).

[wraithdu]

Oh holy mother of crap, now that FileFindNextFile() returns directory information in @extended (and it is fixed in the beta), it is FREAKIN FAST!!

Recursive search test of C:\ drive, 129618 files / folders:

Test for directory using StringInStr(FileGetAttrib($file), "D"): ~38 seconds

Test for directory using @extended: ~6.5 seconds

Nice! Great work!

[Valik]

Just a thought: wouldn't it be more natural and logical to invoke the OnAutoItExitRegister-ed functions in the reverse order of their registration, just like in any stack?

Done in the next beta:

Changed: AutoIt exit callback functions are called in reverse order of registration.

[jchd]

Done in the next beta:

Very nice job. Thank you again.

[kjcdude]

_StringAddThousandsSep() is still in the String file by the way.

[Valik]

_StringAddThousandsSep() is still in the String file by the way.

I have no idea why that file was not omitted when I removed all other traces of that function. It should be completely gone in the next version and if it's not AutoIt is officially haunted.

[Jon]

I have no idea why that file was not omitted when I removed all other traces of that function. It should be completely gone in the next version and if it's not AutoIt is officially haunted.

[GEOSoft]

Do we interpret that as an admission of guilt?

[trancexx]

Do we interpret that as an admission of guilt?

I believe the accent was on haunt part.

He haunts? Bad Jon!

[Valik]

Do we interpret that as an admission of guilt?

The onus of guilt lies with either a poltergeist or with me. I blamed the file and I was the last one who touched _StringAddThousandsSep(). I was checking to make sure nobody had accidentally re-committed it. The last changes were when I inserted one of your rewrites. For some reason when I made the original commit that file was not modified... even though I had modified it. It's possible it was not saved in the editor or that I somehow accidentally reverted it. It's been a few weeks so I honestly don't remember if there were any strange circumstances around it. I do, however, remember deleting the function from the file. I don't have an explanation on why that file was not part of the commit, however.

[jchd]

Is it possible to have _InetGetSource use the value passed to HttpSetUserAgent() instead of the fixed string "AutoIt v3"? Some sites choke at weird / unknown UserAgent values.

Of course it's easy to extract the function and modify it to suit one's needs but this defeats the purpose of std UDFs.

Very low priority, obviously.

[Valik]

The function should just be rewritten to use InetRead(). Or removed completely since InetRead() does the exact same thing but comes with all the proxy-related features for free.

[vdo]

Not being an inside AutoIT Developer, I'm not sure if I'm "allowed" to post in here or not,

but I have a question for whomever fixed #779 - infinite loop on Exit. I just wanted

to bring this question before the person who dealt with this bug track, hence the "Developer Chat."

I have the same issue with the current 3.3.0.0, and don't believe I have a "malformed" GUI, though

the problem occurs upon exit, anytime after exiting a particular GUI, which is formed the same way

as others in the script (which cause no problems). I'm not ready to go to the beta until it's stable,

as this is a commercial product.

Could you please expound on the exact issue you encountered in this "bug" (or alleged bug )?

I'm having trouble tracking it down due to the nature of the bug, though I know the sequence of

events.

Thanks, and sorry if this is the wrong place for this. Please move it to the correct place, once

the correct developer is identified, or PM would be fine with me.

Thanks again in advance.

-vdo

[Valik]

Not being an inside AutoIT Developer, I'm not sure if I'm "allowed" to post in here or not,

but I have a question for whomever fixed #779 - infinite loop on Exit. I just wanted

to bring this question before the person who dealt with this bug track, hence the "Developer Chat."

I have the same issue with the current 3.3.0.0, and don't believe I have a "malformed" GUI, though

the problem occurs upon exit, anytime after exiting a particular GUI, which is formed the same way

as others in the script (which cause no problems). I'm not ready to go to the beta until it's stable,

as this is a commercial product.

Could you please expound on the exact issue you encountered in this "bug" (or alleged bug )?

I'm having trouble tracking it down due to the nature of the bug, though I know the sequence of

events.

Thanks, and sorry if this is the wrong place for this. Please move it to the correct place, once

the correct developer is identified, or PM would be fine with me.

Thanks again in advance.

-vdo

CreateWindow() can sometimes fail to create a window (For example, if specifying WS_EX_LAYERED and WS_CHILD together). There was no code to test that CreateWindow() failed thus allowing a NULL HWND into the internal data structures. This caused things to freak out when the windows were being cleaned up. The fix was to ensure CreateWindow() returned a valid window.

The same fix can be written in AutoIt. Simply test that GUICreate() returns anything other than 0.

[vdo]

CreateWindow() can sometimes fail to create a window (For example, if specifying WS_EX_LAYERED and WS_CHILD together). There was no code to test that CreateWindow() failed thus allowing a NULL HWND into the internal data structures. This caused things to freak out when the windows were being cleaned up. The fix was to ensure CreateWindow() returned a valid window.

The same fix can be written in AutoIt. Simply test that GUICreate() returns anything other than 0.

Thanks for the info, Valik. In my case, the window is created. I am not testing the value, but use GUIDelete on

exit of the GUI, and the window closes, so I assumed it's non-null. It is only on exit from the script that CPU goes

to 50%, and the process hangs.

For this hang to happen, I also need to not merely enter and exit the GUI, but click on one of 6 specific button controls

(which perform simple functions on a seperate process, and return). Further, the functions performed by the

button controls execute and seem to work OK, so the controls are also apparently being created correctly.

Would things also "freak out" if controls [supposed to be] created within the GUI fail to be created correctly (or

deleted on GUIDelete)?

The only real oddity in my code is that I [need to] switch to MessageLoop Mode on entry to the GUI, and

switch back to Event Mode (immediately after GUIDelete).

Is there anything wrong with doing this?