Latest Beta

[NELyon]

3.2.11.5 (24th March, 2008) (Beta)

- Added: REGEXPCLASS in Advanced control definition.

- Added: "start" and "count" parameters added to StringInStr().

- Added #182: GUICtrlSetDefColor(), GUICtrlSetDefBkColor().

- Fixed: Resizing GUI before GUISetState().

- Fixed #183: radio fired when GUI reactivated.

Coooooool

Very useful.

[-Ultima-]

Oh, hah, I just realized that I could've called GUISetState(@SW_HIDE) right after I created the dialog, and I wouldn't have to go through all the craziness I mentioned... Silly me. The problem is (IMO) still something worth looking over, though (or maybe something about it needs to be clarified somewhere?).

Edited March 24, 2008 by -Ultima-

[-Ultima-]

Hm, regarding the parent/child window accelerator issue... I just noticed a bad consequence of the "unexpected" behavior... Currently, my parent window has "Delete" in its accelerator table, and my child dialog has an input control. Naturally, one would expect that "Delete" would work on the input control, but because the parent dialog is using the key as an accelerator, the key doesn't work in the child dialog. It doesn't seem to me like there's any way around this as things currently are...

Edit: Well, I suppose it's always possible to unset all the accelerators in the parent window when it loses focus (and reset them when it regains focus), but uh, that's an ugly hack at best.

Edited March 27, 2008 by -Ultima-

[Jon]

3.2.11.6 (13th April, 2008) (Beta)

- Added #39: Added parent window parameter to MsgBox(), FileSelectFolder(), FileOpenDialog(), FileSaveDialog().

- Added #79: X, Y, W, H in advanced control definitions.

- Fixed #195: Impossible to compile a script with GUICtrlSetDef..Color().

- Fixed #193: crash when GUICtrldelete() of a already deleted Ctrl.

- Fixed: Resizing GUI before GUISetState() (again).

UDFs:

Added: _GDIPlus_DrawImagePoints (Malkey)

Added: 21 _WinAPI_xxxx examples (Gary)

Fixed: Constants declared in Constants.au3 and ScrollBarConstants.au3

Fixed: _GDIPlus_DrawImagePoints Documentation (Malkey)

Added: _GUICtrlAVI_IsPlaying (Gary)

Added: _GUICtrlButton_GetNote, _GUICtrlButton_GetNoteLength, _GUICtrlButton_GetSplitInfo

_GUICtrlButton_SetNote, _GUICtrlButton_SetShield, _GUICtrlButton_SetSplitInfo

_GUICtrlComboBox_GetCueBanner, _GUICtrlComboBox_SetCueBanner, _GUICtrlMonthCal_GetCalendarBorder

_GUICtrlMonthCal_GetCalendarCount, _GUICtrlMonthCal_SetCalendarBorder, _GUICtrlListView_GetFocusedGroup

_GUICtrlListView_GetGroupCount, _GUICtrlListView_GetGroupInfoByIndex, _GUICtrlListView_GetGroupRect (Gary)

Updated: _GUICtrlButton_Create, _GUICtrlButton_GetIdealSize, _GUICtrlMonthCal_Create, _GUICtrlListView_SetGroupInfo (Gary)

Added: _GUICtrlButton_SetDontClick (Gary)

Edited April 13, 2008 by GaryFrost
Added UDF info

[Jon]

http://www.autoitscript.com/autoit3/files/beta/autoit

3.2.11.7 (15th April, 2008) (Beta)

- Added: X, Y, W, H in advanced window definitions.

- Fixed: GUI crash introduced into last beta.

- Fixed: An attempt to FileDelete() a file that was just executed with RunWait() would sometimes fail.

[-Ultima-]

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

Global $GUIMain = GUICreate(@AutoItVersion, 150, 100, Default, Default, $WS_OVERLAPPEDWINDOW)
GUICtrlCreateMenu("&File")
GUICtrlCreateListView("Column", 5, 5, 140, 70)
GUISetState()

While GUIGetMsg() <> $GUI_EVENT_CLOSE
WEnd

Bug: If you resize the window, you'll notice the listview's height jump. This happens only if you have a menu -- comment the menu line out, and the height won't jump.

(I have a feeling this isn't the first time I've seen this regression...)

Edited April 18, 2008 by -Ultima-

[Jon]

IIRC adding a menu changes the client size which alters the sizing code. I thought we'd fixed that long ago but I think fixing another resize/crash issue has caused a regression.

[James]

GuiCtrlSetDef..Color. WOW That's cool!

[GEOSoft]

GuiCtrlSetDef..Color. WOW That's cool!

I thought so too, unfortunatly it didn't work compiled when first introduced. Glad to see that one fixed. Now we don't have to set the font for individual controls or loop through them to set it for all.

[James]

I thought so too, unfortunatly it didn't work compiled when first introduced. Glad to see that one fixed. Now we don't have to set the font for individual controls or loop through them to set it for all.

I only just found it was available today. I should really read the updates more often. Glad to see everything is fixed though. Saves us all having to wait longer and more bug complaints.

[Jon]

3.2.11.8 (19th April, 2008) (Beta)

AutoIt:

- Added #212: Added parent window parameter to InputBox().

- Fixed #213: GUISetAccelerator() regression since 3.2.11.6.

- Fixed #214: Regression in GUI resizing code when menus are present.

AU3Info:

- Changed: Controls are always highlighted when using the finder tool.

- Changed: Controls are not highlighted by default.

- Changed: Control description gives the advanced version of class and instance.

[Jon]

Oops.

3.2.11.9 (19th April, 2008) (Beta)

AutoIt:

- Fixed: Regression in right-click/context menus.

[GEOSoft]

Now you went and did it !! Two updates so close together broke my near perfect collection of AutoIt versions. 11.8 was replaced with 11.9 before I had a chance to DL it.

Thanks Jon. I always like it when things get fixed, it's even better than when things get added.

[jpm]

Now you went and did it !! Two updates so close together broke my near perfect collection of AutoIt versions. 11.8 was replaced with 11.9 before I had a chance to DL it.

Thanks Jon. I always like it when things get fixed, it's even better than when things get added.

you can get it in the archive dir

[GEOSoft]

you can get it in the archive dir

Thanks JP. I wouldn't want to miss a broken version.

[jpm]

Thanks JP. I wouldn't want to miss a broken version.

no more broken than .7 or .6. I think the .9 was related with internal recoding at .5 time.

[-Ultima-]

Hm, regarding the parent/child window accelerator issue... I just noticed a bad consequence of the "unexpected" behavior... Currently, my parent window has "Delete" in its accelerator table, and my child dialog has an input control. Naturally, one would expect that "Delete" would work on the input control, but because the parent dialog is using the key as an accelerator, the key doesn't work in the child dialog. It doesn't seem to me like there's any way around this as things currently are...

Edit: Well, I suppose it's always possible to unset all the accelerators in the parent window when it loses focus (and reset them when it regains focus), but uh, that's an ugly hack at best.

Hm, any word on the status of this problem? I'm somewhat pushy about it because I would really prefer to use accelerators over global hotkeys for grabbing user keyboard shortcut inputs, but this behavior is making things tough. You'll see the problem I described in action here, only, on a wider (and hence, much more annoying) scale -- I've a fair number of accelerators registered.

[Valik]

Ultima, you should know by now that this isn't the right place for this. You post in the wrong place and then want updates on it? Don't you think that's asking a little much?

[-Ultima-]

You're right (of course ), and I humbly apologize for this. I wasn't really sure if it was fit to be reported on Trac, but in retrospect, I guess a simple status change in Trac after a report would settle that. Sorry again!

[Jon]

http://www.autoitscript.com/autoit3/files/beta/autoit

3.2.11.10 (21st April, 2008) (Beta)

AutoIt:

- Fixed #185: GUI performance problem when creating a large number of windows.

- Changed: Tried to make each GUI window have an independent accelerator table.