Latest Beta

[BrettF]

Sweet... But how is someone able to create a GUI with 65535 controls?? Thats a damn lol...

[MrCreatoR]

- Changed: Maximum controls in a GUI window 4093 -> 65535.

Thanks for that (and the others of course) change!

Sweet... But how is someone able to create a GUI with 65535 controls?? Thats a damn lol...

It's not so hard when you create a dynamic ListView, every item is a control

[BrettF]

Thanks for that (and the others of course) change!

It's not so hard when you create a dynamic ListView, every item is a control

Good point

[Jon]

3.2.11.3 (18th March, 2008) (Beta)

- Changed: PCRE regular expression engine updated to 7.6.

- Added #128: GUISetAccelerators().

- Fixed: Modified AutoUpdateIt.au3 to work under x64.

UDFs:

Fixed: $tagREBARINFO declaration (Zedna)

Added: _GUICtrlRebar_GetBarInfo, _GUICtrlRebar_SetBarInfo (Gary)

Edited March 18, 2008 by GaryFrost
Added UDF Info

[-Ultima-]

Woo! Excellent stuff =]

Quick question: is it normal/expected that accelerators set for a particular window would be activated even if another window (a child window) is focused?

[Jon]

Woo! Excellent stuff =]

Quick question: is it normal/expected that accelerators set for a particular window would be activated even if another window (a child window) is focused?

Good question. I have no idea...

[Valik]

That doesn't sound right to me.

[MrCreatoR]

The best solution is to have an Optional parameter to set it globaly, or just for the parent window.

[Jon]

Well, I'm calling the internal accelerator APIs correctly (I think). So first thing before we start adding more flags is to work out if this is "Normal" accelerator behavior for "child" windows. It may well be. If I press Ctrl+S in Word it saves, even when I have a child document in focus...

[Valik]

I do not want to see an option added either way. If this is standard behavior, you, as the user should handle it by doing a simple check to see if the window has focus, if it's really that important to you. There are already a ton of non-standard "features" in the GUI code that could be handled with minimal user code, we don't need to add more.

Edit: Jon, I don't think Word would use accelerators. Everything in Office/Visual Studio uses COM interfaces. Keyboard bindings are tied to an object, I think. The simplest thing to do is take the accelerators sample on MSDN and add a second window to it and then see under what conditions the accelerator works/doesn't work.

Edited March 19, 2008 by Valik

[Jon]

Hmm, it looks like the window handle in TranslateAccelerator() is not actually used to determine whether or not to translate an accelerator keypress, it is simply used as the output of the resulting translated accelerator. I should probably just add a simple check and only call TranslateAccelerator when the MSG and hWND match.

[Jon]

Actually, no. If you had child windows and a single acclerator table you would probably set the acclerator table on the parent and run TranslateAccelerator() on the parent. This would end up sending WM_COMMAND messages to the parent WndProc which end up triggering the same WM_COMMAND no matter the focus...

[-Ultima-]

If this is standard behavior, you, as the user should handle it by doing a simple check to see if the window has focus, if it's really that important to you.

I'm also opposed to adding another option to Opt(). Adding a check to the events is exactly what I intend on doing, assuming it is normal behavior. I bring this up only because I don't want to add checks to later find that they've become unnecessary after a bugfix (if, indeed, it is a bug -- I don't know ). "Better to clarify now than later" is basically what I thought Edited March 20, 2008 by -Ultima-

[Jon]

Ooh, this little nuggest changes things:

The system also maintains accelerator tables for each application. An application can define any number of accelerator tables for use with its own windows. A unique 32-bit handle (HACCEL) identifies each table. However, only one accelerator table can be active at a time for a specified thread. The handle to the accelerator table passed to the TranslateAccelerator function determines which accelerator table is active for a thread. The active accelerator table can be changed at any time by passing a different accelerator-table handle to TranslateAccelerator.

Looks like I can remove the winhandle option as you can only have one active anyway.

[Jon]

3.2.11.4 (20th March, 2008) (Beta)

- Added #78: REGEXPCLASS in Advanced Windows definition.

- Fixed #177: Pixel...() does not accept optional hwnd parameter.

- Fixed #173: Advanced window descriptions only reading to the first ;

UDFs:

- Fixed: _Timer_KillTimer array assignment correction (-Ultima-)

Edited March 20, 2008 by GaryFrost
Added UDF Changes

[MrCreatoR]

3.2.11.4 (20th March, 2008) (Beta)

- Added #78: REGEXPCLASS in Advanced Windows definition.

- Fixed #177: Pixel...() does not accept optional hwnd parameter.

- Fixed #173: Advanced window descriptions only reading to the first ;

Thank you! Thank you! i have been waiting for this looong time

[Bowmore]

3.2.11.4 (20th March, 2008) (Beta)

- Added #78: REGEXPCLASS in Advanced Windows definition.

It would be a nice to have if REGEXPCLASS could also be used for controls.

I often need to resort to using REGEXP for matching .net control class names such as 'WindowsForms10.BUTTON.app.0.2e0c681' as the part after .app changes on each build.

Thanks for the fix of bug #173

Bowmore

[Jon]

It would be a nice to have if REGEXPCLASS could also be used for controls.

Done. Will be in next beta.

[Jon]

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.

[-Ultima-]

- Fixed: Resizing GUI before GUISetState()

I'm curious... In what manner did this bug manifest? I ask because my experience with using WinSetPos() with GUISetState() has been a bit annoying. As it currently is, if I have controls anchored in a certain way ($GUI_DOCKBOTTOM, for example), and I change the height of the dialog before running GUISetState(), the control doesn't actually dock to the bottom (it stays in place).

I notice that it's fixed in this version of AutoIt, but only partially. If I resize the dialog again, the control moves somewhat erratically. Take the following snippet as an example:

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

Global $iWidth  = 200
Global $iHeight = 150
Global $iCount = 1

Global $hGUI = GUICreate("Test " & @AutoItVersion, $iWidth, $iHeight)
Global $hButton = GUICtrlCreateButton("Button", $iWidth - 60, $iHeight - 30, 50, 20)
GUICtrlSetResizing($hButton, $GUI_DOCKBOTTOM + $GUI_DOCKSIZE)

buttonPos()

;GUISetState()

WinMove($hGUI, "", Default, Default, Default, $iHeight - 50)
buttonPos()

GUISetState()

WinMove($hGUI, "", Default, Default, Default, $iHeight + 100)
buttonPos()

While GUIGetMsg() <> $GUI_EVENT_CLOSE
WEnd

Func buttonPos()
    Local $iButtonPos = ControlGetPos($hGUI, "", $hButton)
    MsgBox(0, StringFormat("Button Top (%d)", $iCount), $iButtonPos[1])
    $iCount += 1
EndFunc

Under AutoIt v3.2.10.0 (up to v3.2.11.4)

Button Top (1): 120

Button Top (2): 120

Button Top (3): 270

Under AutoIt v3.2.11.5

Button Top (1): 120

Button Top (2): 45

Button Top (3): 270

You'll notice that the second messagebox is displaying the desired top position for the button in 3.2.11.5 (unlike in previous versions), but after you resize the window again, the button (unexpectedly) jumps off the window.

Normally, this wouldn't be a problem for many/most people (I wouldn't expect so anyway), but in my case, I create a dialog that remains hidden until needed, and is resized depending on the condition under which it needs to be unhidden. Since the dialog can be hidden/unhidden any number of times during the runtime of the program, the user eventually runs into this problem of missing controls. To combat this, I have to create the dialog off screen, call GUISetState() to unhide the dialog, hide it again with GUISetState(), then move it to the desired initial position -- quite cumbersome.

Just as a note, if you uncomment the first call to GUISetState(), everything works as expected (basically, it's a simplification of my workaround).

Edited March 24, 2008 by -Ultima-