Help File/Documentation Issues. (Discussion Only)

[pixelsearch]

13 hours ago, mLipok said:

Could somebody show example when Test 1 result is different from Test 2 ?

 

; Local $hWnd_2 = GUICreate("Window 2", Default, Default, -1, -1, -1, -1, $hWnd_0) ; owned window
Local $hWnd_2 = GUICreate("Window 2", Default, Default, -1, -1, $WS_CHILD, -1, $hWnd_0) ; child window

[pixelsearch]

For the record, I found a possible issue with the extended style $WS_EX_MDICHILD
Though the window is created with this extended style, its value doesn't appear with AutoIt Window Info Tool or with _WinAPI_GetWindowLong etc...
To make it appear, I need to force it, after the window creation, with _WinAPI_SetWindowLong
Don't know if it's only on my computer or if it can be reproduced on other computers.

Here is an example, just look at the Console after you close the MsgBox :
* First  line indicates 0x00000100 (the forced Exstyle $WS_EX_WINDOWEDGE)
* Second line indicates 0x00000140 ($WS_EX_WINDOWEDGE + $WS_EX_MDICHILD which is 0x00000040)

If you think it is a bug, then I'll create a Trac Ticket with a simpler script than the following :

expandcollapse popup

#include <MsgBoxConstants.au3>
#include <WinAPISysWin.au3>
#include <WindowsConstants.au3>

Opt("MustDeclareVars", 1)

Example()

Func Example()
    Local $hGUI, $hMdiChild

    $hGUI = GUICreate("")
    WinSetTitle($hGUI, "", "GUI  " & $hGUI)
    GuiCtrlCreateLabel("Label in GUI", 200, 0, 90, 20)
    GUICtrlSetBkColor(-1, 0xFFFF00)

    $hMdiChild = GUICreate("", 300, 200, 0, 0, -1, $WS_EX_MDICHILD, $hGUI)
    WinSetTitle($hMdiChild, "", "MdiChild  " & $hMdiChild)
    GuiCtrlCreateLabel("Label in MdiChild", 200, 0, 90, 20)
    GUICtrlSetBkColor(-1, 0x00FFFF)

    GUISetState(@SW_SHOW, $hGUI)
    GUISetState(@SW_SHOW, $hMdiChild)

    MsgBox($MB_TOPMOST, "Parent/Ancestors of MdiChild window "  & $hMdiChild , _
        "Reminder : $hGUI = " & $hGUI & @crlf & _
        "Reminder : $hMdiChild = " & $hMdiChild & @crlf & @crlf & _
        "_WinAPI_GetParent = " & _WinAPI_GetParent($hMdiChild) & " (owner, not parent +++)" & @crlf & @crlf & _
        "_WinAPI_GetAncestor (Parent)   = " & _WinAPI_GetAncestor($hMdiChild, $GA_PARENT) & " (desktop)" & @crlf & _
        "_WinAPI_GetAncestor (Root)     = " & _WinAPI_GetAncestor($hMdiChild, $GA_ROOT) & " (itself)" & @crlf & _
        "_WinAPI_GetAncestor (Owner)  = "   & _WinAPI_GetAncestor($hMdiChild, $GA_ROOTOWNER) & " (gui)")

    ConsoleWrite("1 - ExStyles of $hMdiChild : 0x" & Hex(_WinAPI_GetWindowLong($hMdiChild, $GWL_EXSTYLE), 8) & @crlf)

    _WinAPI_SetWindowLong($hMdiChild, $GWL_EXSTYLE, $WS_EX_MDICHILD)
    ConsoleWrite("2 - ExStyles of $hMdiChild : 0x" & Hex(_WinAPI_GetWindowLong($hMdiChild, $GWL_EXSTYLE), 8) & @crlf)

    Do
    Until GUIGetMsg() = -3

    GuiDelete($hMdiChild)
    GuiDelete($hGUI)
EndFunc   ;==>Example

 

Edited April 13 by pixelsearch
typo

[donnyh13]

5 hours ago, jpm said:

Many Thanks I have committed something similar based on wikipedia x11

Looks good @jpm, Thanks very much!

Best regards,

Donny

[mLipok]

6 hours ago, pixelsearch said:

Here is an example, just look at the Console after you close the MsgBox :
* First  line indicates 0x00000100 (the forced Exstyle $WS_EX_WINDOWEDGE)
* Second line indicates 0x00000140 ($WS_EX_WINDOWEDGE + $WS_EX_MDICHILD which is 0x00000040)

If you think it is a bug, then I'll create a Trac Ticket with a simpler script than the following :

First What I did is to change:

$hMdiChild = GUICreate("", 300, 200, 0, 0, -1, $WS_EX_MDICHILD, $hGUI)

to

$hMdiChild = GUICreate("", 300, 200, 0, 0, -1, BitOR($WS_EX_WINDOWEDGE, $WS_EX_MDICHILD), $hGUI)

 

but it still won't work and I have the same result as you have:

Quote

1 - ExStyles of $hMdiChild : 0x00000100
2 - ExStyles of $hMdiChild : 0x00000140

 

[mLipok]

modified example:

expandcollapse popup

;~ https://www.autoitscript.com/forum/topic/153782-help-filedocumentation-issues-discussion-only/page/43/#findComment-1551537
#include <MsgBoxConstants.au3>
#include <WinAPISysWin.au3>
#include <WindowsConstants.au3>

Opt("MustDeclareVars", 1)

Example()

Func Example()
    Local $hGUI, $hMdiChild

    $hGUI = GUICreate("")
    WinSetTitle($hGUI, "", "GUI  " & $hGUI)
    GUICtrlCreateLabel("Label in GUI", 200, 0, 90, 20)
    GUICtrlSetBkColor(-1, 0xFFFF00)

    $hMdiChild = GUICreate("", 300, 200, 0, 0, -1, BitOR($WS_EX_WINDOWEDGE, $WS_EX_MDICHILD), $hGUI)
    WinSetTitle($hMdiChild, "", "MdiChild  " & $hMdiChild)
    GUICtrlCreateLabel("Label in MdiChild", 200, 0, 90, 20)
    GUICtrlSetBkColor(-1, 0x00FFFF)

    GUISetState(@SW_SHOW, $hGUI)
    GUISetState(@SW_SHOW, $hMdiChild)

    ConsoleWrite("====" & @CRLF)

    ConsoleWrite( _
            "> Parent/Ancestors of MdiChild window " & $hMdiChild & @CRLF & _
            "Reminder : $hGUI = " & $hGUI & @CRLF & _
            "Reminder : $hMdiChild = " & $hMdiChild & @CRLF & @CRLF & _
            "_WinAPI_GetParent = " & _WinAPI_GetParent($hMdiChild) & " (owner, not parent +++)" & @CRLF & @CRLF & _
            "_WinAPI_GetAncestor (Parent)   = " & _WinAPI_GetAncestor($hMdiChild, $GA_PARENT) & " (desktop)" & @CRLF & _
            "_WinAPI_GetAncestor (Root)     = " & _WinAPI_GetAncestor($hMdiChild, $GA_ROOT) & " (itself / $hMdiChild)" & @CRLF & _
            "_WinAPI_GetAncestor (Owner)    = " & _WinAPI_GetAncestor($hMdiChild, $GA_ROOTOWNER) & " (gui / $hGUI)" & @CRLF & _
            "")
    ConsoleWrite("====" & @CRLF)

    ConsoleWrite("- TEST 1 - ExStyles of $hMdiChild : 0x" & Hex(_WinAPI_GetWindowLong($hMdiChild, $GWL_EXSTYLE), 8) & @CRLF)
    _WinAPI_SetWindowLong($hMdiChild, $GWL_EXSTYLE, $WS_EX_MDICHILD)
    ConsoleWrite("- TEST 2 - ExStyles of $hMdiChild : 0x" & Hex(_WinAPI_GetWindowLong($hMdiChild, $GWL_EXSTYLE), 8) & @CRLF)

    ConsoleWrite("====" & @CRLF)

    Do
    Until GUIGetMsg() = -3

    GUIDelete($hMdiChild)
    GUIDelete($hGUI)
EndFunc   ;==>Example

 

results:

Quote

====
> Parent/Ancestors of MdiChild window 0x00000000015C0C3C
Reminder : $hGUI = 0x0000000000400B94
Reminder : $hMdiChild = 0x00000000015C0C3C

_WinAPI_GetParent = 0x0000000000400B94 (owner, not parent +++)

_WinAPI_GetAncestor (Parent)   = 0x000000000001000C (desktop)
_WinAPI_GetAncestor (Root)     = 0x00000000015C0C3C (itself / $hMdiChild)
_WinAPI_GetAncestor (Owner)    = 0x0000000000400B94 (gui / $hGUI)
====
- TEST 1 - ExStyles of $hMdiChild : 0x00000100
- TEST 2 - ExStyles of $hMdiChild : 0x00000140
====
 

 

Edited April 13 by mLipok

[pixelsearch]

@mLipok As we noticed, AutoIt doesn't add the extended style $WS_EX_MDICHILD in a window created with the "fake" extended style $WS_EX_MDICHILD :

GUICreate(..., $WS_EX_MDICHILD)

Thanks to @funkey, we can see in his script how to create genuine MDI child windows which will have a $WS_EX_MDICHILD extended style (checked) . So probably Jon didn't want at all to indicate that AutoIt GUI's created with the fake $WS_EX_MDICHILD style were real MDI child windows, that's why he removed the $WS_EX_MDICHILD extended style indicated by the user, to create a non-child window instead.

As you know, real MDI child windows are confined in the client area of their MDI client window, which isn't the case of fake AutoIt $WS_EX_MDICHILD windows which are not confined at all etc...

Maybe this could be indicated in the help file : "though the user indicates $WS_EX_MDICHILD when creating the GUI, you won't retrieve this extended style if you check for it after the GUI creation"

[jpm]

By the way the @funkey script does not work under current version

anyway I will add something in the doc about simulation

Edited April 18 by jpm

[pixelsearch]

2 hours ago, jpm said:

anyway I will add something in the doc about simulation

Thanks Jean-Paul, it will be useful to users who check for $WS_EX_MDICHILD after they create a GUI (indicating this extended style at creation) then wonder why it is not found anymore in the GUI extended styles after creation.

2 hours ago, jpm said:

By the way the @funkey script does not work under current version

You're right, here are the few changes required to make it work with newer versions of AutoIt :

Remove 8 lines :
#include <WinAPIEx.au3>
Global Const $IDC_ARROW = 32512
Global Const $WM_MDIGETACTIVE = 553
Global Const $WM_MDICREATE = 544
Global Const $WM_MDIACTIVATE = 546
Global Const $WM_MDITILE = 550
Global Const $WM_MDICASCADE = 551
Global Const $MF_ENABLED = 0

Add 2 lines :
#include <WinAPIRes.au3>
#include <WinAPISysWin.au3>

Also, IF you want the MDI frame window ($hGUI in our case) to be maximizable & resizable, change this line :

; Global $hGui = GUICreate("AutoIt MDI-Example by funkey", -1, -1, -1, -1, BitOR($WS_MAXIMIZE, $GUI_SS_DEFAULT_GUI))

Global $hGui = GUICreate("AutoIt MDI-Example by funkey", -1, -1, -1, -1, BitOR($WS_MAXIMIZE, $WS_OVERLAPPEDWINDOW))

Feature : to create a new MDI child window : Menu => File => New child
This will automatically add an entry in : Menu => Window (one of the MDI features)

[jpm]

Many Thanks

 I will not add this standard way to have standard child usable

Cheers

[mLipok]

_WinAPI_SetThemeAppProperties help says:

Quote

After you set the flags, you must send a WM_THEMECHANGED message for the changes to take effect.

but as far as I see the example is not sending this message .

Could somebody propose a fix or at least explain this case to me ?

 

#include <GUIConstantsEx.au3>
#include <WinAPITheme.au3>

Local $iTheme = _WinAPI_GetThemeAppProperties()

Local $hForm = GUICreate("WinAPI Get/Set Theme AppProperties (v" & @AutoItVersion & ")", 310, 360)
GUISetFont(8.5, 400, 0, 'MS Shell Dlg', $hForm)
GUICtrlCreateGroup('Group', 10, 10, 140, 95)
GUICtrlCreateCheckbox('Check1', 22, 26, 120, 23)
GUICtrlCreateCheckbox('Check2', 22, 49, 120, 23)
GUICtrlCreateCheckbox('Check3', 22, 72, 120, 23)
GUICtrlCreateGroup('Group', 160, 10, 140, 95)
GUICtrlCreateRadio('Radio1', 172, 26, 120, 23)
GUICtrlCreateRadio('Radio2', 172, 49, 120, 23)
GUICtrlCreateRadio('Radio3', 172, 72, 120, 23)
GUICtrlCreateButton('OK', 120, 330, 70, 23)
_WinAPI_SetThemeAppProperties($STAP_ALLOW_NONCLIENT)
GUICtrlCreateTab(10, 118, 292, 206)
GUICtrlCreateTabItem('Tab1')
GUICtrlCreateTabItem('Tab2')
GUICtrlCreateTabItem('')
_WinAPI_SetThemeAppProperties($iTheme)

GUISetState(@SW_SHOW)

Do
Until GUIGetMsg() = $GUI_EVENT_CLOSE

 

[mLipok]

On 4/21/2026 at 9:29 AM, mLipok said:

Could somebody propose a fix or at least explain this case to me ?

I would like to politely remind you about this problem.

[argumentum]

When you're building a bunch of UDFs, you copy and paste a bunch of references, SetThemeAppProperties(MSDN) has that remark in their page and we just copy it to our help file, and it is not used in the example to change all controls, just that tab control and the reapply the previous.
We would need an example where we change a whole GUI to know how that works. 

[WildByDesign]

I ran into an issue with _GUICtrlRebar_SetBKColor and _GUICtrlRebar_SetTextColor. Both use the same example code and both fail to color the background and text.

I was not able to get them to work. @Nine got them working, so I decided to dig in some more and figure out what was happening.

For the record, I was removing the theme and running the two coloring functions right before GUISetState() but the problem was that was after the bands were created.

Interestingly, if you add the coloring functions between bands, it will only color the bands created after the coloring functions and only those bands after the coloring functions can be colored later on. Very weird.

There are two parts to the bug:

• Theme must be removed now before coloring functions (likely was not needed pre-XP times)
  • _WinAPI_SetWindowTheme($hReBar, "", "")
• _GUICtrlRebar_SetBKColor and _GUICtrlRebar_SetTextColor must be called before any bands are created
  • Once done before bands are created, thankfully, color can be changed again and again

First, I remove theme and set default Windows colors immediately after _GUICtrlRebar_Create:

; remove theme to allow coloring
    _WinAPI_SetWindowTheme($hReBar, "", "")

    ; set initial rebar colors
    _GUICtrlRebar_SetBKColor($hReBar, _WinAPI_GetSysColor($COLOR_BTNFACE))
    _GUICtrlRebar_SetTextColor($hReBar, _WinAPI_GetSysColor($COLOR_WINDOWTEXT))

If not, the custom colors set later will not work.

Here is my proposed fix:

expandcollapse popup

;#include "Extras\HelpFileInternals.au3"
#include "C:\Program Files (x86)\AutoIt3\Examples\Helpfile\Extras\HelpFileInternals.au3"

#include <AutoItConstants.au3>
#include <GUIConstantsEx.au3>
#include <GuiReBar.au3>
#include <GuiToolbar.au3>
#include <WinAPIConstants.au3>
#include <WinAPITheme.au3>
#include <WindowsStylesConstants.au3>
#include <WindowsSysColorConstants.au3>

Example()

Func Example()
    Local $hGui, $idBtn_Exit, $hReBar, $hToolbar, $idInput
    Local Enum $e_idNew = 1000, $e_idOpen, $e_idSave, $e_idHelp

    $hGui = GUICreate("Rebar", 400, 396, -1, -1, BitOR($WS_MINIMIZEBOX, $WS_CAPTION, $WS_POPUP, $WS_SYSMENU, $WS_MAXIMIZEBOX))

    ; create the rebar control
    $hReBar = _GUICtrlRebar_Create($hGui, BitOR($CCS_TOP, $WS_BORDER, $RBS_VARHEIGHT, $RBS_AUTOSIZE, $RBS_BANDBORDERS))

    ; remove theme to allow coloring
    _WinAPI_SetWindowTheme($hReBar, "", "")

    ; set initial rebar colors
    _GUICtrlRebar_SetBKColor($hReBar, _WinAPI_GetSysColor($COLOR_BTNFACE))
    _GUICtrlRebar_SetTextColor($hReBar, _WinAPI_GetSysColor($COLOR_WINDOWTEXT))

    _MemoCreate(2, 100, 396, 250, $WS_VSCROLL)

    ; create a toolbar to put in the rebar
    $hToolbar = _GUICtrlToolbar_Create($hGui, BitOR($TBSTYLE_FLAT, $CCS_NORESIZE, $CCS_NOPARENTALIGN))

    ; Add standard system bitmaps
    Switch _GUICtrlToolbar_GetBitmapFlags($hToolbar)
        Case 0
            _GUICtrlToolbar_AddBitmap($hToolbar, 1, -1, $IDB_STD_SMALL_COLOR)
        Case 2
            _GUICtrlToolbar_AddBitmap($hToolbar, 1, -1, $IDB_STD_LARGE_COLOR)
    EndSwitch

    ; Add buttons
    _GUICtrlToolbar_AddButton($hToolbar, $e_idNew, $STD_FILENEW)
    _GUICtrlToolbar_AddButton($hToolbar, $e_idOpen, $STD_FILEOPEN)
    _GUICtrlToolbar_AddButton($hToolbar, $e_idSave, $STD_FILESAVE)
    _GUICtrlToolbar_AddButtonSep($hToolbar)
    _GUICtrlToolbar_AddButton($hToolbar, $e_idHelp, $STD_HELP)

    ; create a input box to put in the rebar
    $idInput = GUICtrlCreateInput("Input control", 0, 0, 120, 20)

    ;add band containing the control
    _GUICtrlRebar_AddBand($hReBar, GUICtrlGetHandle($idInput), 120, 200, "Name:")

    ; add band containing the control to the beginning of rebar
    _GUICtrlRebar_AddToolBarBand($hReBar, $hToolbar, "", 0)

    $idBtn_Exit = GUICtrlCreateButton("Exit", 150, 360, 100, 25)
    GUICtrlSetState($idBtn_Exit, $GUI_DEFBUTTON)
    GUICtrlSetState($idBtn_Exit, $GUI_FOCUS)

    GUISetState(@SW_SHOW)

    _GUICtrlRebar_SetBandStyleBreak($hReBar, 1)

    _MemoWrite("========== Bar Color ==========")
    _MemoWrite("Previous BK Color..: " & _GUICtrlRebar_SetBKColor($hReBar, Int(0x00008B)))
    _MemoWrite("BK Color...........: " & _GUICtrlRebar_GetBKColor($hReBar))
    _MemoWrite("Previous Text Color: " & _GUICtrlRebar_SetTextColor($hReBar, Int(0xFFFFFF)))
    _MemoWrite("Text Color.........: " & _GUICtrlRebar_GetTextColor($hReBar))

    ; matching color scheme for toolbar and rebar
    _GUICtrlRebar_SetColorScheme($hReBar, Int(0x00008B), Int(0x00008B))
    _GUICtrlToolbar_SetColorScheme($hToolbar, Int(0x00008B), Int(0x00008B))

    While 1
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE, $idBtn_Exit
                Exit
        EndSwitch
    WEnd
EndFunc   ;==>Example

You will notice at the end:

; matching color scheme for toolbar and rebar
    _GUICtrlRebar_SetColorScheme($hReBar, Int(0x00008B), Int(0x00008B))
    _GUICtrlToolbar_SetColorScheme($hToolbar, Int(0x00008B), Int(0x00008B))

That is not required but simply for beautification. Remove those and you will see why.

Anyway, hope this is helpful. The code example is 100% identical between both functions _GUICtrlRebar_SetBKColor and _GUICtrlRebar_SetTextColor and therefore both need fixing/updating.

[jpm]

Thanks, I intend to add 

    _WinAPI_SetWindowTheme($hReBar, "", "")

inside the_GUICtrlRebar_Create() do you agree?

for beautification do you think that _GUICtrl()Rebar_SetBKColor() must be updated too?

[WildByDesign]

42 minutes ago, jpm said:

nside the_GUICtrlRebar_Create() do you agree?

Yes, I agree. I like your idea of putting fix directly inside _GUICtrlRebar_Create function.

Removing the theme from rebar control with _WinAPI_SetWindowTheme is not enough by itself to fix the _GUICtrlRebar_SetBKColor and _GUICtrlRebar_SetTextColor. Those will still fail to work.

But with your idea of updating _GUICtrlRebar_Create directly, we can fix that too. We must remove theme and also set default colors. Then _GUICtrlRebar_SetBKColor and _GUICtrlRebar_SetTextColor will automatically work.

Func _GUICtrlRebar_Create($hWnd, $iStyles = 0x513)
    Local Const $ICC_BAR_CLASSES = 0x00000004 ; toolbar
    Local Const $ICC_COOL_CLASSES = 0x00000400 ; rebar

    Local $iStyle = BitOR($__GUICTRLCONSTANT_WS_CHILD, $__GUICTRLCONSTANT_WS_VISIBLE, $__REBARCONSTANT_WS_CLIPCHILDREN, $__REBARCONSTANT_WS_CLIPSIBLINGS)
    If $iStyles <> BitOR($__REBARCONSTANT_CCS_TOP, $RBS_VARHEIGHT) Then
        $iStyle = BitOR($iStyle, $iStyles)
    Else
        $iStyle = BitOR($iStyle, $__REBARCONSTANT_CCS_TOP, $RBS_VARHEIGHT)
    EndIf

    Local $tICCE = DllStructCreate('dword;dword')
    DllStructSetData($tICCE, 1, DllStructGetSize($tICCE))
    DllStructSetData($tICCE, 2, BitOR($ICC_BAR_CLASSES, $ICC_COOL_CLASSES))

    Local $aCall = DllCall('comctl32.dll', 'int', 'InitCommonControlsEx', 'struct*', $tICCE)
    If @error Then Return SetError(@error, @extended, 0)
    If $aCall[0] = 0 Then Return SetError(-2, 0, 0)

    Local $nCtrlID = __GuiCtrl_GetNextGlobalID($hWnd)
    If @error Then Return SetError(@error, @extended, 0)

    Local $hReBar = _WinAPI_CreateWindowEx(0, $__REBARCONSTANT_ClassName, "", $iStyle, 0, 0, 0, 0, $hWnd, $nCtrlID)
    If @error Then Return SetError(-1, -1, 0)

    ; added here
    _WinAPI_SetWindowTheme($hReBar, "", "")
    _GUICtrlRebar_SetBKColor($hReBar, _WinAPI_GetSysColor($COLOR_BTNFACE))
    _GUICtrlRebar_SetTextColor($hReBar, _WinAPI_GetSysColor($COLOR_WINDOWTEXT))

    Return $hReBar
EndFunc   ;==>_GUICtrlRebar_Create

This will allow the other functions to work now. Those fixes (in function above) are required.

The other post where I used _GUICtrlRebar_SetColorScheme and _GUICtrlToolbar_SetColorScheme to improve the overall look was just extra. Those were not required to fix the problem.

Thank you

[argumentum]

Func _GUICtrlRebar_Create($hWnd, $iStyles = 0x513, $iRemoveWindowTheme = 1)
    Local Const $ICC_BAR_CLASSES = 0x00000004 ; toolbar
    Local Const $ICC_COOL_CLASSES = 0x00000400 ; rebar

    Local $iStyle = BitOR($__GUICTRLCONSTANT_WS_CHILD, $__GUICTRLCONSTANT_WS_VISIBLE, $__REBARCONSTANT_WS_CLIPCHILDREN, $__REBARCONSTANT_WS_CLIPSIBLINGS)
    If $iStyles <> BitOR($__REBARCONSTANT_CCS_TOP, $RBS_VARHEIGHT) Then
        $iStyle = BitOR($iStyle, $iStyles)
    Else
        $iStyle = BitOR($iStyle, $__REBARCONSTANT_CCS_TOP, $RBS_VARHEIGHT)
    EndIf

    Local $tICCE = DllStructCreate('dword;dword')
    DllStructSetData($tICCE, 1, DllStructGetSize($tICCE))
    DllStructSetData($tICCE, 2, BitOR($ICC_BAR_CLASSES, $ICC_COOL_CLASSES))

    Local $aCall = DllCall('comctl32.dll', 'int', 'InitCommonControlsEx', 'struct*', $tICCE)
    If @error Then Return SetError(@error, @extended, 0)
    If $aCall[0] = 0 Then Return SetError(-2, 0, 0)

    Local $nCtrlID = __GuiCtrl_GetNextGlobalID($hWnd)
    If @error Then Return SetError(@error, @extended, 0)

    Local $hReBar = _WinAPI_CreateWindowEx(0, $__REBARCONSTANT_ClassName, "", $iStyle, 0, 0, 0, 0, $hWnd, $nCtrlID)
    If @error Then Return SetError(-1, -1, 0)

    ; added here
    If $iRemoveWindowTheme Then ; allow the user to *not* clear the theme
        _WinAPI_SetWindowTheme($hReBar, "", "")
        _GUICtrlRebar_SetBKColor($hReBar, _WinAPI_SwitchColor(_WinAPI_GetSysColor($COLOR_BTNFACE)))
        _GUICtrlRebar_SetTextColor($hReBar, _WinAPI_SwitchColor(_WinAPI_GetSysColor($COLOR_WINDOWTEXT)))
    EndIf

    Return $hReBar
EndFunc   ;==>_GUICtrlRebar_Create

If we are going to add this, we should give user the ability to not add this. This way is not as script breaking and/or forced.

..and since we're at it, clarify the _GUICtrlRebar_GetBKColor() example: ( COLORREF )

...
;    old
    _MemoWrite("========== Bar Color ==========")
    _MemoWrite("Previous BK Color..: " & _GUICtrlRebar_SetBKColor($hReBar, Int(0x00008B)))
    _MemoWrite("BK Color...........: " & _GUICtrlRebar_GetBKColor($hReBar))
    _MemoWrite("Previous Text Color: " & _GUICtrlRebar_SetTextColor($hReBar, Int(0xFFFFFF)))
    _MemoWrite("Text Color.........: " & _GUICtrlRebar_GetTextColor($hReBar))
...
;   new ; clarify that is BGR instead of RGB ; that it needs not be an integer either
    _MemoWrite("========== Bar Color ==========")
    _MemoWrite("Previous BK Color..: " & _GUICtrlRebar_SetBKColor($hReBar, _WinAPI_SwitchColor(0x8B0000)))
    _MemoWrite("BK Color...........: 0x" & Hex(_WinAPI_SwitchColor(_GUICtrlRebar_GetBKColor($hReBar)), 6))
    _MemoWrite("Previous Text Color: " & _GUICtrlRebar_SetTextColor($hReBar, _WinAPI_SwitchColor(0xFFFFFF)))
    _MemoWrite("Text Color.........: 0x" & Hex(_WinAPI_SwitchColor(_GUICtrlRebar_GetTextColor($hReBar)), 6))
...

 

Edited yesterday at 02:58 PM by argumentum

[WildByDesign]

34 minutes ago, argumentum said:

If we are going to add this, we should give user the ability to not add this. This way is not as script breaking and/or forced.

That's a good point. Just to clarify for my own understanding, having $iRemoveWindowTheme = 1 as default means that the function is fixed by default?

And if someone using older scripts notices breakage, they would simply call the function with False instead? Do I understand that correctly?

[argumentum]

Just now, WildByDesign said:

Do I understand that correctly?

Yes you did. AutoIt right now doesn't even run on Windows XP but, if you're going to add something like this, it should be clearly noted.
...and maybe add a note to the help file regarding win32controls on newer Windows versions, and the work around.

[argumentum]

1 hour ago, argumentum said:

..and since we're at it, clarify the _GUICtrlRebar_GetBKColor() example: ( COLORREF )

Spoiler

is a "COLORREF" BGR ?

 

Yes, a Windows COLORREF value uses the BGR byte layout. [1, 2]

When viewed as a 32-bit hexadecimal integer (DWORD), a Microsoft Win32 COLORREF value is explicitly structured in memory as 0x00BBGGRR. [1, 3]

Byte Breakdown

If you look at the raw bytes of a COLORREF integer from the lowest-order byte (least significant) to the highest-order byte (most significant), the channels sit in this order: [3]

 

• Byte 0 (Low-order): Red (RR)
• Byte 1: Green (GG)
• Byte 2: Blue (BB)
• Byte 3 (High-order): Padding / Zero (00) [4, 5, 6, 7]

Why is it called BGR if Red is first?

The confusion comes down to how humans read numbers versus how computers read memory (Endianness):

 

• As an Integer Literal: When writing a hexadecimal literal in C/C++ (like 0x00FF0000), the Blue channel is written on the left and Red is on the right (0x00BBGGRR). Because Blue occupies the higher numeric position, it is commonly referred to as a BGR integer format.
• As raw bytes in Little-Endian memory: Because Windows x86/x64 systems are Little-Endian, they store the lowest-order byte first in physical memory. Therefore, the bytes are physically arranged sequentially as [Red, Green, Blue, 00]. [1, 2, 3, 8, 9]

Safe Manipulation

To avoid manually swapping bytes or breaking compatibility, Microsoft provides native macros in Windef.h to safely extract or create these values: [10]

 

• Creation: Use the RGB(r, g, b) macro. Under the hood, it shifts the values into the BGR integer alignment: ((BYTE)(r)|((WORD)((BYTE)(g))<<8)|(((DWORD)(BYTE)(b))<<16)).
• Extraction: Use GetRValue(color), GetGValue(color), and GetBValue(color) to pull individual channels without guessing the bit position. [10, 11, 12, 13]

If you are working with graphics libraries like OpenCV (which naturally processes native image buffers in BGR byte order) or writing colors into Windows GDI, keeping track of this byte arrangement prevents your reds and blues from accidentally flipping. [13, 14, 15]

If you are mapping these values to another environment, let me know:

 

• What programming language or library are you using?
• Are you trying to pass COLORREF data directly into an image buffer (like a bitmap)?
• Do you need to convert it to a standard web format like RGBA or hex string?

 

[1] https://learnopencv.com

[2] https://docwiki.embarcadero.com

[3] https://www.autoitscript.com

[4] https://forums.codeguru.com

[5] https://www.daniweb.com

[6] https://help.autodesk.com

[7] https://learn.microsoft.com

[8] https://news.ycombinator.com

[9] https://forums.codeguru.com

[10] https://learn.microsoft.com

[11] https://forums.codeguru.com

[12] https://ofekshilon.com

[13] https://stackoverflow.com

[14] https://blog.roboflow.com

[15] https://github.com

 

 

but `https://learn.microsoft.com/en-us/windows/win32/gdi/colorref` claims is RGB. Why would they want to drive me crazy? 😅

 

The documentation calls it "RGB" because Microsoft is referring to the conceptual data components (Red, Green, Blue), not the physical or literal memory layout. [1, 2]

If you look closely at that exact Microsoft Learn page for COLORREF, they admit the truth right in the Remarks section: [1]

"When specifying an explicit RGB color, the COLORREF value has the following hexadecimal form: 0x00bbggrr." [1]

They are absolutely speaking out of both sides of their mouth, and here is why they designed this linguistic trap:

1. "RGB" is a Concept, "BGR" is a Layout [1, 3]

In computer science, "RGB" is widely used as a generic umbrella term for any color space that uses Red, Green, and Blue channels. When Microsoft writes "used to specify an RGB color," they just mean "This type defines a color using light mixing, not CMYK or YUV." They treat "RGB" as the name of the concept, regardless of which order the bytes actually sit in. [1]

2. The Little-Endian Memory Paradox

This is the ultimate culprit behind the madness. Because Windows was built for Intel little-endian processors, memory is read "backwards". [3, 4]

If you look at how the RGB() macro is actually written in the Windows headers:

#define RGB(r,g,b) ((COLORREF)(((BYTE)(r)|((WORD)((BYTE)(g))<<8))|(((DWORD)(BYTE)(b))<<16)))

 

• Red is shifted by 0 bits (stays at the lowest position).
• Green is shifted left by 8 bits.
• Blue is shifted left by 16 bits.

When you write it down as a standard 32-bit mathematical integer, Blue is on the left: 0x00BBGGRR (BGR). But when that integer is dumped into your RAM chips, Little-Endian architecture flips the bytes, meaning the bytes physically sit in memory as [Red, Green, Blue, 00]. [1, 3, 5]

So to an engineer looking at a raw RAM hex dump, it's RGB. To an engineer looking at a literal integer value in a C++ debugger, it's BGR. [3]

3. Microsoft Duality: COLORREF vs RGBQUAD

To make things even wilder, Microsoft actually has two major color types in GDI: [6]

 

• COLORREF: As an integer, it is 0x00BBGGRR.
• RGBQUAD: Used for bitmaps, this is a literal C-struct containing rgbBlue, rgbGreen, rgbRed, rgbReserved. As an integer, it is 0x00RRGGBB. [1, 3, 6, 7]

The documentation authors used "RGB" as a blanket term across GDI to keep high-level developers sane, but in doing so, they created a lifelong headache for graphics and systems developers trying to align pixel buffers. [5, 7]

If you want to quickly verify how your current project sees it, I can give you a quick 1-line C++ or Python snippet to print out a test color and see if the bytes flip on your system. What language are you currently using?

 

[1] https://learn.microsoft.com

[2] https://learn.microsoft.com

[3] https://stackoverflow.com

[4] https://www.reddit.com

[5] https://www.reddit.com

[6] https://learn.microsoft.com

[7] https://stackoverflow.com

 

"...The documentation calls it "RGB" because Microsoft is referring to the conceptual data components (Red, Green, Blue), not the physical or literal memory layout...."
Funny enough, the link is https://learn.microsoft.com/en-us/windows/win32/gdi/colorref. Why not call it BGR !. 
Anywayz, more rants can be found here. I'll go take my pressure medication now 🤪

[WildByDesign]

I'm not sure if this is the right place to report a bug with a function from the standard UDFs, but I've got a bug in _GUICtrlRebar_Create.

;Func _GUICtrlRebar_Create($hWnd, $iStyles = 0x513)
Func _GUICtrlRebar_Create($hWnd, $iStyles = BitOR($CCS_TOP, $RBS_VARHEIGHT))
    Local Const $ICC_BAR_CLASSES = 0x00000004 ; toolbar
    Local Const $ICC_COOL_CLASSES = 0x00000400 ; rebar

    Local $iStyle = BitOR($__GUICTRLCONSTANT_WS_CHILD, $__GUICTRLCONSTANT_WS_VISIBLE, $__REBARCONSTANT_WS_CLIPCHILDREN, $__REBARCONSTANT_WS_CLIPSIBLINGS)
    If $iStyles <> BitOR($__REBARCONSTANT_CCS_TOP, $RBS_VARHEIGHT) Then
        $iStyle = BitOR($iStyle, $iStyles)
    Else
        $iStyle = BitOR($iStyle, $__REBARCONSTANT_CCS_TOP, $RBS_VARHEIGHT)
    EndIf

    Local $tICCE = DllStructCreate('dword;dword')
    DllStructSetData($tICCE, 1, DllStructGetSize($tICCE))
    DllStructSetData($tICCE, 2, BitOR($ICC_BAR_CLASSES, $ICC_COOL_CLASSES))

    Local $aCall = DllCall('comctl32.dll', 'int', 'InitCommonControlsEx', 'struct*', $tICCE)
    If @error Then Return SetError(@error, @extended, 0)
    If $aCall[0] = 0 Then Return SetError(-2, 0, 0)

    Local $nCtrlID = __GuiCtrl_GetNextGlobalID($hWnd)
    If @error Then Return SetError(@error, @extended, 0)

    Local $hReBar = _WinAPI_CreateWindowEx(0, $__REBARCONSTANT_ClassName, "", $iStyle, 0, 0, 0, 0, $hWnd, $nCtrlID)
    If @error Then Return SetError(-1, -1, 0)

    Return $hReBar
EndFunc   ;==>_GUICtrlRebar_Create

According to help file, default is $CCS_TOP, $RBS_VARHEIGHT

Notice how the original Func line (commented out) has 0x513 as default. Well, I'm guessing that does not equal the BitOR for those two values. I added the Func line below that with the BitOR and that seems to go through the function properly and work as intended.