Leaderboard

Screenshot: The only downside is that it makes the border lines between parts thicker. But that is better than having to do all of the workarounds to ownerdraw it and such. Thank you so much to everyone who helped dig into this issue for me. I am thankful and appreciate your time on this.

@WildByDesign does this work for you ? #include <GUIConstantsEx.au3> #include <GuiStatusBar.au3> #include <WinAPIGdi.au3> #include <WinAPIRes.au3> #include <WinAPISysWin.au3> #include <WinAPITheme.au3> #include <WindowsConstants.au3> Opt("MustDeclareVars", 1) Global $g_hGui, $g_hSizebox, $g_hOldProc, $g_hBrush, $g_hStatus, $g_iHeight Example() ;============================================== Func Example() Local Const $SBS_SIZEBOX = 0x08, $SBS_SIZEGRIP = 0x10 Local $iW = 250, $iH = 100, $iBkColor = 0x00FF00 $g_hGui = GUICreate("Resize corner", $iW, $iH, -1, -1, $WS_OVERLAPPEDWINDOW) GUISetBkColor($iBkColor) ;----------------- ; Create a sizebox window (Scrollbar class) BEFORE creating the StatusBar control $g_hSizebox = _WinAPI_CreateWindowEx(0, "Scrollbar", "", $WS_CHILD + $WS_VISIBLE + $SBS_SIZEBOX, _ 0, 0, 0, 0, $g_hGui) ; $SBS_SIZEBOX or $SBS_SIZEGRIP ; Subclass the sizebox (by changing the window procedure associated with the Scrollbar class) Local $hProc = DllCallbackRegister('ScrollbarProc', 'lresult', 'hwnd;uint;wparam;lparam') $g_hOldProc = _WinAPI_SetWindowLong($g_hSizebox, $GWL_WNDPROC, DllCallbackGetPtr($hProc)) Local $hCursor = _WinAPI_LoadCursor(0, $OCR_SIZENWSE) _WinAPI_SetClassLongEx($g_hSizebox, -12, $hCursor) ; $GCL_HCURSOR = -12 $g_hBrush = _WinAPI_CreateSolidBrush($iBkColor) ;----------------- $g_hStatus = _GUICtrlStatusBar_Create($g_hGui, -1, "", $WS_CLIPSIBLINGS) ; ClipSiblings style +++ Local $aParts[3] = [75, 150, -1] _GUICtrlStatusBar_SetParts($g_hStatus, $aParts) _GUICtrlStatusBar_SetText($g_hStatus, "Part 0", 0) _GUICtrlStatusBar_SetText($g_hStatus, "Part 1", 1) _GUICtrlStatusBar_SetText($g_hStatus, "Part 2", 2) ; to allow the setting of StatusBar BkColor at least under Windows 10 _WinAPI_SetWindowTheme($g_hStatus, "", "") ; Set status bar background color _GUICtrlStatusBar_SetBkColor($g_hStatus, $iBkColor) $g_iHeight = _GUICtrlStatusBar_GetHeight($g_hStatus) + 3 ; change the constant (+3) if necessary GUIRegisterMsg($WM_SIZE, "WM_SIZE") GUISetState() While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd _GUICtrlStatusBar_Destroy($g_hStatus) _WinAPI_DeleteObject($g_hBrush) _WinAPI_DestroyCursor($hCursor) _WinAPI_SetWindowLong($g_hSizebox, $GWL_WNDPROC, $g_hOldProc) DllCallbackFree($hProc) GUIDelete($g_hGui) EndFunc ;==>Example ;============================================== Func ScrollbarProc($hWnd, $iMsg, $wParam, $lParam) ; Andreik's If $hWnd = $g_hSizebox Then Switch $iMsg Case $WM_ERASEBKGND Local $tRect = _WinAPI_GetClientRect($hWnd) _WinAPI_FillRect($wParam, $tRect, $g_hBrush) Return True Case $WM_PAINT Local $tPAINTSTRUCT Local $hDC = _WinAPI_BeginPaint($hWnd, $tPAINTSTRUCT) Local $tRect = _WinAPI_CreateRect($tPAINTSTRUCT.Left, $tPAINTSTRUCT.Top, $tPAINTSTRUCT.Right, $tPAINTSTRUCT.Bottom) _WinAPI_FillRect($hDC, $tRect, $g_hBrush) _WinAPI_EndPaint($hWnd, $tPAINTSTRUCT) Return 0 EndSwitch EndIf Return _WinAPI_CallWindowProc($g_hOldProc, $hWnd, $iMsg, $wParam, $lParam) EndFunc ;==>ScrollbarProc ;============================================== Func WM_SIZE($hWnd, $iMsg, $wParam, $lParam) #forceref $iMsg, $wParam, $lParam If $hWnd = $g_hGUI Then Local $aSize = WinGetClientSize($g_hGui) _GUICtrlStatusBar_Resize($g_hStatus) WinMove($g_hSizebox, "", $aSize[0] - $g_iHeight, $aSize[1] - $g_iHeight, $g_iHeight, $g_iHeight) _WinAPI_ShowWindow($g_hSizebox, (BitAND(WinGetState($g_hGui), $WIN_STATE_MAXIMIZED) ? @SW_HIDE : @SW_SHOW)) EndIf Return $GUI_RUNDEFMSG EndFunc ;==>WM_SIZE

That is why I just fixed the maximized thing but left the rest of it as is. One can add a button, or label, or what not, to do what the status bar does which is to show a status.

So for dark mode it was: _WinAPI_SetWindowTheme($hStatus, "DarkMode_Explorer", "Explorer") Light mode (haven't tested light mode yet): _WinAPI_SetWindowTheme($hStatus, "Explorer", "Explorer")

@pixelsearch@argumentum I was able to fix this properly without workaround. It ended up just being a matter of applying the theme with _WinAPI_SetWindowTheme on that status bar control.

..playing with it. All I did is add @pixelsearch idea. Am personally not too sure about GUICtrlStatusBars because, is a GUI thing. Is about how the graphic interface looks and feel, and in that regard, the Win32 looks may not feel as homogeneous as it did back in Win95 with the now, Win11 and darkmode. ( my 2 cents of fears and views )

Fixed: added this line in both scripts above : _WinAPI_ShowWindow($g_hSizebox, (BitAND(WinGetState($g_hGui), $WIN_STATE_MAXIMIZED) ? @SW_HIDE : @SW_SHOW))

Haha, yes I was trying same with the -1 part

Yes, that works perfectly now. Thank you.

It should be possible if its size was based on the StatusBar height (instead of a 20 pixels constant), like this : $g_iHeight = _GUICtrlStatusBar_GetHeight ($g_hStatus) + 3 ; change the constant (+3) if necessary I'm amending the script above, is the display correct on your computer now ?

OK sorry, i make new topic. It's not a same code like this. PROBLEM SOLVED

Thank you. I have found my problem with your code. I don't check when i click on submit button, im always in while. Problem Solved

This is a spin off the thread from here. I've moved this out of the collab space so I don't feel guilty about making sweeping changes when the mood hits me. But I'm still more than happy for this to be a community project at heart. Just a quick comment about the code: for this API, it looks like we need to construct some objects internally, which is a bit of a learning curve - but hopefully this example will provide a bit of background as to whats happening there... Original Attempt: Updated example 20/4 - Load media file, progress/seek bar. PlayerDemo 1.1.zip

No shit, Yuchan is back.... This isn't going to end well.

See comment "Only process the statusbar" #include <ButtonConstants.au3> #include <GUIConstantsEx.au3> #include <GuiStatusBar.au3> #include <WindowsConstants.au3> #include <Array.au3> #include <File.au3> #include <WinAPI.au3> #region ### START Koda GUI section ### Form= $Form1 = GUICreate("Form1", 615, 437, 192, 124) GUICtrlSetDefColor(0x000000) GUICtrlSetDefBkColor(0xFF0000) $hStatus = _GUICtrlStatusBar_Create($Form1) GUIRegisterMsg($WM_DRAWITEM, "_WM_DRAWITEM") _GUICtrlStatusBar_SetText($hStatus, "test", 0, $SBT_OWNERDRAW) Global $global_StatusBar_Text = "Part 1" $Button1 = GUICtrlCreateButton("Button1", 176, 136, 75, 25) GUISetState(@SW_SHOW) #endregion ### END Koda GUI section ### While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit Case $Button1 ; $d = _FileListToArrayRec(@ScriptDir & "\ico", "*.ico", 0, 1, 0, 1) For $x = 1 To 100 ; ConsoleWrite($d[$x] & @CRLF) Sleep(20) $global_StatusBar_Text = $x _WinAPI_RedrawWindow($hStatus) ; _GUICtrlStatusBar_SetText($hStatus, $x & " " & $x, 0, $SBT_OWNERDRAW) Next EndSwitch WEnd Func _WM_DRAWITEM($hWnd, $Msg, $wParam, $lParam) #forceref $Msg, $wParam, $lParam Local $tDRAWITEMSTRUCT = DllStructCreate("uint CtlType;uint CtlID;uint itemID;uint itemAction;uint itemState;HWND hwndItem;HANDLE hDC;long rcItem[4];ULONG_PTR itemData", $lParam) If DllStructGetData($tDRAWITEMSTRUCT, "hwndItem") <> $hStatus Then Return $GUI_RUNDEFMSG ; Only process the statusbar Local $itemID = DllStructGetData($tDRAWITEMSTRUCT, "itemID") ;part number Local $hDC = DllStructGetData($tDRAWITEMSTRUCT, "hDC") Local $tRect = DllStructCreate("long left;long top;long right; long bottom", DllStructGetPtr($tDRAWITEMSTRUCT, "rcItem")) Local $iTop = DllStructGetData($tRect, "top") Local $iLeft = DllStructGetData($tRect, "left") Local $hBrush Switch $itemID Case 0 $hBrush = _WinAPI_CreateSolidBrush(0x0000FF) ; Backgound Color _WinAPI_FillRect($hDC, DllStructGetPtr($tRect), $hBrush) _WinAPI_SetTextColor($hDC, 0x00FF00) ; Font Color _WinAPI_SetBkMode($hDC, $TRANSPARENT) DllStructSetData($tRect, "top", $iTop + 1) DllStructSetData($tRect, "left", $iLeft + 1) _WinAPI_DrawText($hDC, $global_StatusBar_Text, $tRect, $DT_LEFT) _WinAPI_DeleteObject($hBrush) EndSwitch $tDRAWITEMSTRUCT = 0 Return $GUI_RUNDEFMSG EndFunc ;==>_WM_DRAWITEM

Tjalve, First, let us deal with handles and ControlIDs. Windows handles are unique identifiers that the OS uses to keep track of everything on the system, such as GUIs and controls, which continually send messages around the system so that everything in the system knows what is going on (which GUI is active, which control has just been actioned, which key was pressed, etc, etc). These messages contain all sorts of data, but essentially explain "which control has just done what". AutoIt tries to make life simple for you by using ControlIDs to identify its native controls - theses IDs are actually the indIces of an internal array of all controls maintained by AutoIt. So when you look for these ControlIDs in a GUIGetMsg loop you are asking AutoIt to access the Windows message stream and pick put those messages which refer to that control - the OnEvent commands work in a similar manner. Now to how the script I posted works. As the UDF functions return handles and not ControlIDs (which as explained above are only returned by AutoIt native functions) we cannot use a GUIGetMsg loop to look for messages, so we have to do it ourselves rather than relying on AutoIt to do it for us. This is where the GUIRegisterMsg command comes into play - it peeks into the Windows message stream and lets us see what is happening. In the script above we are asking to look at WM_NOTIFY messages - a pretty comprehensive set which, amongst many other things, covers selecting items in a TreeView. When a WM_NOTIFY message is detected in the stream AutoIt then runs the allocated function or "handler" where we can examine the message in detail: We create a data structure to look at the detailed content of the message - this data is stored by Windows and we use one of the message parameters ($lParam) to access it. We then check that this message was indeed sent by the treeview by looking inside the data structure - we can ignore the vast majority of messages which have been sent by other controls. Finally we check if the message deals with a change of the selected item in the treeview - and if it does than we know that we have found the message we were looking for. And there you have it - because the treeview was created by a UDF and not by an internal AutoIt function, we had to recreate what AutoIt does for us "under the hood" and peer into the Windows message stream ourselves to intercept the message telling us that the user had selected another item in the treeview. You can see the same thing happening with tab controls if you read the Tabs tutorial in the Wiki - if you create the tab with the UDF you need to do a lot more work to make it work correctly. I hope that the above explanation makes you realise how much AutoIt does for you behind the scenes - please ask again if anything is still unclear. M23