Leaderboard

I was before retiring in Basic software development as Windows Core So I can tell you that the solution comes with generating an assembly code based on a run time implementing the AutoIt builtin functions That need to defined something as as C compiler, that's a tremending job at least for me Today Autoit is based on a interpreting byte code corresponding to AutoIt builtin functions which is not too bad from my point of view Cheers

Hello! Just letting everyone know that I'm still hard at work on this. Decided to make some major changes to the structure once again. Now I can continue to lay out the GUI. Now it is based on an event queue. Any time an action is performed or information is requested, the object pushes it to a queue which announces to other objects that have subscribed to the queue. I'm hoping this will allow me to implement an undo/redo!

I found in my old testing on the subject I hope it is usefullGUIDarkMode-Jpm.zip t

Is a theme ( BIB3 by niivu ) and the best ( and I would say the only way ) to have a theme in windows. The user shouldn't have to choose each app in a color. The OS should have a homogeneous theme throughout. This "dark mode" per app is wrong, but is what M$ does ¯\_(ツ)_/¯

But you could hack the NM_CUSTOMDRAW. Not so great but it is working : ; From Nine #include <GUIConstants.au3> #include <WindowsConstants.au3> #include <StructureConstants.au3> #include <WinAPI.au3> #include <FrameConstants.au3> Global Const $tagNMCUSTOMDRAWINFO = $tagNMHDR & ";dword DrawStage;handle hdc;" & $tagRECT & ";dword_ptr ItemSpec;uint ItemState;lparam lItemParam;" Global $idBut Example() Func Example() Local $hGUI = GUICreate("Example") $idBut = GUICtrlCreateButton("Test", 10, 10, 100, 30) GUICtrlCreateButton("Standard", 10, 50, 100, 30) GUIRegisterMsg($WM_NOTIFY, WM_NOTIFY) GUISetState() While True Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop Case $idBut ConsoleWrite("Button was pressed" & @CRLF) EndSwitch WEnd EndFunc ;==>Example Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam) Local $tInfo = DllStructCreate($tagNMCUSTOMDRAWINFO, $lParam) If $tInfo.IDFrom = $idBut And $tInfo.Code = $NM_CUSTOMDRAW Then Local $tRECT = DllStructCreate($tagRECT, DllStructGetPtr($tInfo, "left")) Switch $tInfo.DrawStage Case $CDDS_PREPAINT _WinAPI_DrawFrameControl($tInfo.hDC, $tRECT, $DFC_BUTTON, (BitAND($tInfo.ItemState, $CDIS_SELECTED) ? $DFCS_PUSHED : 0) + $DFCS_BUTTONPUSH) _WinAPI_InflateRect($tRECT, -3, -3) Local $hBrush = _WinAPI_CreateSolidBrush(BitAND($tInfo.ItemState, $CDIS_HOT) ? 0xCDEF : 0xAAAA) _WinAPI_FillRect($tInfo.hDC, $tRECT, $hBrush) _WinAPI_DeleteObject($hBrush) Return $CDRF_NOTIFYPOSTPAINT Case $CDDS_POSTPAINT _WinAPI_InflateRect($tRECT, -6, -6) _WinAPI_SetTextColor($tInfo.hDC, 0xFFFFFF) _WinAPI_SetBkColor($tInfo.hDC, BitAND($tInfo.ItemState, $CDIS_HOT) ? 0xCDEF : 0xAAAA) _WinAPI_DrawText($tInfo.hDC, GUICtrlRead($tInfo.IDFrom), $tRECT, BitOR($DT_CENTER, $DT_VCENTER)) EndSwitch EndIf Return $GUI_RUNDEFMSG EndFunc ;==>WM_NOTIFY

WildByDesign, Rainy day forecast tomorrow - something to keep me occupied! M23

perfect ! thanks

@WildByDesign Thanks for the kind words ! I just edited the last script, removing these 2 lines : Local $idLabel = GUICtrlCreateLabel("", 0, 0, $iChildW, $iChildH) GUICtrlSetState(-1, $GUI_DISABLE) Resizing the Child Gui using the ratio way (as in the script) doesn't require the use of a disabled label (which is another way of resizing a Child Gui)

This is absolute perfection! Thank you so much. 🍷 I know it may seem like a lot of "extra" here, for anyone else that may be following along or reading later. I really enjoy smooth GUI movement (flicker-free) with WS_EX_COMPOSITED, particularly combined with the GUIFrame UDF in this case. But at the same time, I am a huge fan of ListViews and use many of them in most of my bigger projects. I love ListViews. So this MDI window trick was a blessing.

Fingers crossed #include <WindowsConstants.au3> #include <GUIConstantsEx.au3> #include <GuiListView.au3> ; DPI DllCall("User32.dll", "bool", "SetProcessDpiAwarenessContext" , "HWND", "DPI_AWARENESS_CONTEXT" -2) Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration Global $g_hGUI, $g_hChild, $g_hChildMDI, $g_aPosChild, $g_aDelta[4], $g_nRatio[4] Example() Func Example() Local $iParentW = 400, $iParentH = 400 Local $iChildW = 320, $iChildH = 320, $iChildX = 40, $iChildY = 40 $g_hGUI = GUICreate("Example", $iParentW, $iParentH, -1, -1, $WS_OVERLAPPEDWINDOW, $WS_EX_COMPOSITED) GUISetBkColor(0x202020) GUISetState(@SW_SHOW, $g_hGUI) $g_hChild = GUICreate("ChildWindow", $iChildW, $iChildH, $iChildX, $iChildY, $WS_CHILD, -1, $g_hGUI) GUISetBkColor(0x606060) GUISetState(@SW_SHOW, $g_hChild) $g_hChildMDI = GUICreate("", 280, 280, 20, 20, $WS_POPUP, BitOr($WS_EX_MDICHILD, $WS_EX_CONTROLPARENT), $g_hChild) GUISetBkColor(0xff00ff) ; add listview Local $idListview = GUICtrlCreateListView("Column1|Column2", 20, 20, 240, 240, -1, BitOR($LVS_EX_FULLROWSELECT, $WS_EX_CLIENTEDGE, $LVS_EX_DOUBLEBUFFER, $LVS_EX_CHECKBOXES)) Local $idLVi_Item1 = GUICtrlCreateListViewItem("1|1", $idListview) Local $idLVi_Item2 = GUICtrlCreateListViewItem("2|2", $idListview) Local $idLVi_Item3 = GUICtrlCreateListViewItem("3|3", $idListview) ; get rid of selection rectangle on listview GUICtrlSendMsg($idListview, $WM_CHANGEUISTATE, 65537, 0) GUISetState(@SW_SHOW, $g_hChildMDI) $g_nRatio[0] = $iChildX / $iParentW $g_nRatio[1] = $iChildY / $iParentH $g_nRatio[2] = $iChildW / $iParentW $g_nRatio[3] = $iChildH / $iParentH _CalcPosAndDelta() GUIRegisterMsg($WM_ENTERSIZEMOVE, "WM_ENTERSIZEMOVE") GUIRegisterMsg($WM_EXITSIZEMOVE, "WM_ENTERSIZEMOVE") GUIRegisterMsg($WM_SIZE, "WM_SIZE") GUIRegisterMsg($WM_MOVE, "WM_MOVE") While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd GUIDelete($g_hChildMDI) GUIDelete($g_hChild) GUIDelete($g_hGUI) EndFunc ;==>Example Func _CalcPosAndDelta() Local $aPosChildMDI = WinGetPos($g_hChildMDI) $g_aPosChild = WinGetPos($g_hChild) For $i = 0 To 3 $g_aDelta[$i] = $g_aPosChild[$i] - $aPosChildMDI[$i] Next EndFunc ;==>_CalcPosAndDelta Func WM_ENTERSIZEMOVE($hWnd, $iMsg, $wParam, $lParam) _CalcPosAndDelta() EndFunc ;==>WM_ENTERSIZEMOVE Func WM_SIZE($hWnd, $iMsg, $wParam, $lParam) If $hWnd = $g_hGUI Then Local $iParentNewCliW = BitAND($lParam, 0xFFFF) ; low word Local $iParentNewCliH = BitShift($lParam, 16) ; high word WinMove($g_hChild, "", $iParentNewCliW * $g_nRatio[0], $iParentNewCliH * $g_nRatio[1], _ $iParentNewCliW * $g_nRatio[2], $iParentNewCliH * $g_nRatio[3]) ; WinMove will use Int coords $g_aPosChild = WinGetPos($g_hChild) WinMove($g_hChildMDI, "", $g_aPosChild[0] - $g_aDelta[0], $g_aPosChild[1] - $g_aDelta[1] , _ $g_aPosChild[2] - $g_aDelta[2], $g_aPosChild[3] - $g_aDelta[3]) EndIf EndFunc ;==>WM_SIZE Func WM_MOVE($hWnd, $iMsg, $wParam, $lParam) If $hWnd = $g_hGUI Then $g_aPosChild = WinGetPos($g_hChild) WinMove($g_hChildMDI, "", $g_aPosChild[0] - $g_aDelta[0], $g_aPosChild[1] - $g_aDelta[1]) EndIf EndFunc ;==>WM_MOVE

That is fantastic. Very efficient. By the way, this is all really quite genius. What a coincidence, I was actually reading this same thread earlier in the morning. Sometimes I spend a good amount of time reading older threads here in the forum because it's literally a gold mine worth of information. Anyways, your technique is working. I've got it working with WS_EX_COMPOSITE and a perfectly working ListView thanks to the MDI GUI trick. I'll post the screenshot and more details in another comment because I just ran out of quota again...

@WildByDesign great result with the listview inside the MDI window So $WS_EX_COMPOSITED is now applied to the GUI (less flicker when resizing the GUI) and doesn't interfere with the "$LVS_EX_DOUBLEBUFFER listview" which is a control of an external MDI window, bravo !

Here is a quick addition of the ListView with LVS_EX_DOUBLEBUFFER. By the way, @pixelsearch, I see that you just edited your example. My ListView addition is based on your example that was originally posted. I still have to check your updated example. #include <WindowsConstants.au3> #include <GUIConstantsEx.au3> #include <GuiListView.au3> ; DPI DllCall("User32.dll", "bool", "SetProcessDpiAwarenessContext" , "HWND", "DPI_AWARENESS_CONTEXT" -2) Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration Global $g_hGUI, $g_hChild, $g_hChildMDI, $g_aPosChild, $g_iDeltaX, $g_iDeltaY Example() Func Example() $g_hGUI = GUICreate("Example", 400, 400, -1, -1, $WS_OVERLAPPEDWINDOW, $WS_EX_COMPOSITED) GUISetBkColor(0x202020) GUISetState(@SW_SHOW, $g_hGUI) $g_hChild = GUICreate("ChildWindow", 320, 320, 40, 40, 0x40000000, -1, $g_hGUI) GUISetBkColor(0x606060) GUISetState(@SW_SHOW, $g_hChild) $g_hChildMDI = GUICreate("", 280, 280, 20, 20, $WS_POPUP, BitOr($WS_EX_MDICHILD, $WS_EX_CONTROLPARENT), $g_hChild) GUISetBkColor(0xff00ff) ; add listview Local $idListview = GUICtrlCreateListView("Column1|Column2", 20, 20, 240, 240, -1, BitOR($LVS_EX_FULLROWSELECT, $WS_EX_CLIENTEDGE, $LVS_EX_DOUBLEBUFFER, $LVS_EX_CHECKBOXES)) Local $idLVi_Item1 = GUICtrlCreateListViewItem("1|1", $idListview) Local $idLVi_Item2 = GUICtrlCreateListViewItem("2|2", $idListview) Local $idLVi_Item3 = GUICtrlCreateListViewItem("3|3", $idListview) ; get rid of selection rectangle on listview GUICtrlSendMsg($idListview, $WM_CHANGEUISTATE, 65537, 0) GUISetState(@SW_SHOW, $g_hChildMDI) _CalcPosAndDelta() GUIRegisterMsg($WM_ENTERSIZEMOVE, "WM_ENTERSIZEMOVE") GUIRegisterMsg($WM_EXITSIZEMOVE, "WM_ENTERSIZEMOVE") GUIRegisterMsg($WM_SIZE, "WM_SIZE") GUIRegisterMsg($WM_MOVE, "WM_SIZE") While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd GUIDelete($g_hChildMDI) GUIDelete($g_hChild) GUIDelete($g_hGUI) EndFunc ;==>Example Func _CalcPosAndDelta() Local $aPosChildMDI = WinGetPos($g_hChildMDI) $g_aPosChild = WinGetPos($g_hChild) $g_iDeltaX = $g_aPosChild[0] - $aPosChildMDI[0] $g_iDeltaY = $g_aPosChild[1] - $aPosChildMDI[1] EndFunc ;==>_CalcPosAndDelta Func WM_ENTERSIZEMOVE($hWnd, $iMsg, $wParam, $lParam) _CalcPosAndDelta() EndFunc ;==>WM_ENTERSIZEMOVE Func WM_SIZE($hWnd, $iMsg, $wParam, $lParam) If $hWnd = $g_hGUI Then $g_aPosChild = WinGetPos($g_hChild) WinMove($g_hChildMDI, "", $g_aPosChild[0] - $g_iDeltaX, $g_aPosChild[1] - $g_iDeltaY) EndIf EndFunc ;==>WM_SIZE

I tried it like this, in the following script. Please note that you can move separately the pink MDI window by dragging it with the mouse (I applied to it the "AutoIt special" Exstyle $WS_EX_CONTROLPARENT) In this script, we don't need (for now) 2 separate functions WM_EXITSIZEMOVE() and WM_MOVE() as their content would duplicate the code found in functions WM_ENTERSIZEMOVE() and WM_SIZE() . This could change in case you'll have to work later on separate functions WM_SIZE() and WM_MOVE() #include <WindowsConstants.au3> #include <GUIConstantsEx.au3> Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration Global $g_hGUI, $g_hChild, $g_hChildMDI, $g_aPosChild, $g_iDeltaX, $g_iDeltaY Example() Func Example() $g_hGUI = GUICreate("Example", 400, 400, -1, -1, $WS_OVERLAPPEDWINDOW, $WS_EX_COMPOSITED) GUISetBkColor(0x202020) GUISetState(@SW_SHOW, $g_hGUI) $g_hChild = GUICreate("ChildWindow", 200, 200, 100, 100, $WS_CHILD, -1, $g_hGUI) GUISetBkColor(0xffffff) GUISetState(@SW_SHOW, $g_hChild) $g_hChildMDI = GUICreate("", 100, 100, 5, 5, $WS_POPUP, BitOr($WS_EX_MDICHILD, $WS_EX_CONTROLPARENT), $g_hChild) GUISetBkColor(0xff00ff) GUISetState(@SW_SHOW, $g_hChildMDI) _CalcPosAndDelta() GUIRegisterMsg($WM_ENTERSIZEMOVE, "WM_ENTERSIZEMOVE") GUIRegisterMsg($WM_EXITSIZEMOVE, "WM_ENTERSIZEMOVE") GUIRegisterMsg($WM_SIZE, "WM_SIZE") GUIRegisterMsg($WM_MOVE, "WM_SIZE") While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd GUIDelete($g_hChildMDI) GUIDelete($g_hChild) GUIDelete($g_hGUI) EndFunc ;==>Example Func _CalcPosAndDelta() Local $aPosChildMDI = WinGetPos($g_hChildMDI) $g_aPosChild = WinGetPos($g_hChild) $g_iDeltaX = $g_aPosChild[0] - $aPosChildMDI[0] $g_iDeltaY = $g_aPosChild[1] - $aPosChildMDI[1] EndFunc ;==>_CalcPosAndDelta Func WM_ENTERSIZEMOVE($hWnd, $iMsg, $wParam, $lParam) _CalcPosAndDelta() EndFunc ;==>WM_ENTERSIZEMOVE Func WM_SIZE($hWnd, $iMsg, $wParam, $lParam) If $hWnd = $g_hGUI Then $g_aPosChild = WinGetPos($g_hChild) WinMove($g_hChildMDI, "", $g_aPosChild[0] - $g_iDeltaX, $g_aPosChild[1] - $g_iDeltaY) EndIf EndFunc ;==>WM_SIZE

Unless there is a specific reason to mix $WS_CHILD and $WS_EX_MDICHILD, you shouldn't do that. All you will get out of it is useless complexity. Now if you want to adapt the child windows to the size of its parent, here one easy way : ; From Nine #include <GUIConstants.au3> #include <WindowsConstants.au3> Opt("MustDeclareVars", True) Global $hChild1, $hChild2, $aPosGUI Example() Func Example() Local $hGUI = GUICreate("Example", 400, 400, Default, Default, $WS_OVERLAPPEDWINDOW, $WS_EX_COMPOSITED) GUISetBkColor(0x202020) GUISetState() $hChild1 = GUICreate("", 200, 200, 100, 100, $WS_POPUP, $WS_EX_MDICHILD, $hGUI) GUISetBkColor(0xFFFFFF) GUISetState() $hChild2 = GUICreate("", 100, 100, 5, 5, $WS_POPUP, $WS_EX_MDICHILD, $hChild1) GUISetBkColor(0xFF00FF) GUISetState() GUIRegisterMsg($WM_SIZE, WM_SIZE) $aPosGUI = WinGetPos($hGUI) While True Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd EndFunc ;==>Example Func WM_SIZE($hWnd, $iMsg, $wParam, $lParam) Local $aPos = WinGetPos($hWnd), $aChild1 = WinGetPos($hChild1), $aChild2 = WinGetPos($hChild2) WinMove($hChild1, "", $aChild1[0], $aChild1[1], $aChild1[2] + $aPos[2] - $aPosGUI[2], $aChild1[3] + $aPos[3] - $aPosGUI[3]) WinMove($hChild2, "", $aChild2[0], $aChild2[1], $aChild2[2] + $aPos[2] - $aPosGUI[2], $aChild2[3] + $aPos[3] - $aPosGUI[3]) $aPosGUI = $aPos EndFunc ;==>WM_SIZE

Oops. I forgot about that. Is that the one called "tristate" or something like that?

This looks great and works really well. Thank you so much. This is very helpful. @argumentum This is significantly better than what I was going to post. Mine used _LVWndProc as well but did not function nearly as well. @NoNameCode By the way, if you haven't seen the awesome dark mode subclassing that @UEZ did recently in this thread, you should check it out. It's definitely the most thorough when it comes to the dark mode subclassing efforts and the final outcome of the dark mode GUI visuals.

@ioa747 I hope it is alright with you for me to share this example here. If not, please let me know and I can remove. I modified the example from @Nine into something that would work well for toolbar buttons and/or buttons with colors for different states that you can customize. The general design is flat, rectangle buttons. It seems to work incredibly well. I may extend if further at some point but at the moment I got distracted with other projects. However, I am definitely going to integrate this into at least one of my projects. ; From Nine #include <GUIConstants.au3> #include <WindowsConstants.au3> #include <StructureConstants.au3> #include <WinAPI.au3> #include <FrameConstants.au3> ; DPI awareness DllCall("User32.dll", "bool", "SetProcessDpiAwarenessContext" , "HWND", "DPI_AWARENESS_CONTEXT" -2) Global $iBackColorDef = 0x202020 Global $iBackColorHot = 0x808080 Global $iBackColorSel = 0x606060 Global $iBackColorDis = 0x000000 Global $iTextColorDef = 0xFFFFFF Global $iTextColorDis = 0xA0A0A0 Global Const $tagNMCUSTOMDRAWINFO = $tagNMHDR & ";dword DrawStage;handle hdc;" & $tagRECT & ";dword_ptr ItemSpec;uint ItemState;lparam lItemParam;" Global $idButton, $idButton2 Example() Func Example() Local $hGUI = GUICreate("Example") GUISetBkColor(0x000000) Local $sFont = "Segoe MDL2 Assets" GUISetFont(14, $FW_NORMAL, $GUI_FONTNORMAL, $sFont) $idButton = GUICtrlCreateButton(ChrW(0xE74D), 100, 100, -1, -1) Local $sFont = "Segoe UI" GUISetFont(14, $FW_NORMAL, $GUI_FONTNORMAL, $sFont) $idButton2 = GUICtrlCreateButton("Button", 100, 160, -1, -1) GUICtrlSendMsg($idButton, $WM_CHANGEUISTATE, 65537, 0) GUIRegisterMsg($WM_NOTIFY, WM_NOTIFY) GUISetState() While True Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop Case $idButton ConsoleWrite("Button1 was pressed" & @CRLF) Case $idButton2 ConsoleWrite("Button2 was pressed" & @CRLF) EndSwitch WEnd EndFunc ;==>Example Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam) Local $tInfo = DllStructCreate($tagNMCUSTOMDRAWINFO, $lParam) If _WinAPI_GetClassName($tInfo.hWndFrom) = "Button" And IsString(GUICtrlRead($tInfo.IDFrom)) And $tInfo.Code = $NM_CUSTOMDRAW Then Local $tRECT = DllStructCreate($tagRECT, DllStructGetPtr($tInfo, "left")) Switch $tInfo.DrawStage Case $CDDS_PREPAINT If BitAND($tInfo.ItemState, $CDIS_HOT) Then ; set hot track back color $hBrush = _WinAPI_CreateSolidBrush($iBackColorHot) EndIf If BitAND($tInfo.ItemState, $CDIS_SELECTED) Then ; set selected back color $hBrush = _WinAPI_CreateSolidBrush($iBackColorSel) EndIf If BitAND($tInfo.ItemState, $CDIS_DISABLED) Then ; set disabled back color $hBrush = _WinAPI_CreateSolidBrush($iBackColorDis) EndIf If Not BitAND($tInfo.ItemState, $CDIS_HOT) And Not BitAND($tInfo.ItemState, $CDIS_SELECTED) And Not BitAND($tInfo.ItemState, $CDIS_DISABLED) Then $hBrush = _WinAPI_CreateSolidBrush($iBackColorDef) EndIf _WinAPI_FillRect($tInfo.hDC, $tRECT, $hBrush) _WinAPI_DeleteObject($hBrush) Return $CDRF_NOTIFYPOSTPAINT Case $CDDS_POSTPAINT _WinAPI_InflateRect($tRECT, -4, -6) If BitAND($tInfo.ItemState, $CDIS_HOT) Then ; set hot track back color _WinAPI_SetBkColor($tInfo.hDC, $iBackColorHot) ; set default text color _WinAPI_SetTextColor($tInfo.hDC, $iTextColorDef) EndIf If BitAND($tInfo.ItemState, $CDIS_SELECTED) Then ; set selected back color _WinAPI_SetBkColor($tInfo.hDC, $iBackColorSel) ; set default text color _WinAPI_SetTextColor($tInfo.hDC, $iTextColorDef) EndIf If BitAND($tInfo.ItemState, $CDIS_DISABLED) Then ; set disabled back color _WinAPI_SetBkColor($tInfo.hDC, $iBackColorDis) ; set disabled text color _WinAPI_SetTextColor($tInfo.hDC, $iTextColorDis) EndIf If Not BitAND($tInfo.ItemState, $CDIS_HOT) And Not BitAND($tInfo.ItemState, $CDIS_SELECTED) And Not BitAND($tInfo.ItemState, $CDIS_DISABLED) Then ; set default back color _WinAPI_SetBkColor($tInfo.hDC, $iBackColorDef) ; set default text color _WinAPI_SetTextColor($tInfo.hDC, $iTextColorDef) EndIf _WinAPI_DrawText($tInfo.hDC, GUICtrlRead($tInfo.IDFrom), $tRECT, BitOR($DT_CENTER, $DT_VCENTER)) EndSwitch EndIf Return $GUI_RUNDEFMSG EndFunc ;==>WM_NOTIFY

This is perfect. I tested with and without ListViews and tested with that new parameter as True and False. Every possible test and scenario worked exactly as expected. I think that is the best solution. Thank you. On a side note: I found the problem (and solution) to the longstanding issue with the frames not showing. Issue with the frames not showing: Does not occur when running script from SciTE or VSCode Frames fail to show 100% of the time when running script from Explorer (or other programs as well) The previously proposed fix _WinAPI_ShowWindow does not work (confirmed) Also tried _WinAPI_SetFocus and various mouse clicking methods and all failed to resolve issue How did I track down the issue? Well, since the issue only occurs when executing the script (from Explorer, etc.), I could not use ConsoleWrite unfortunately. So I had to place a bunch of MsgBox's in various places until I nailed it down. The script is failing in the _GUIFrame_Create function. It basically pauses the script until you click anywhere in the GUI or titlebar. Failing line: GUISetState(@SW_SHOW, $hParent) It doesn't make sense to me why it fails (or technically pauses the script there). But if you put a MsgBox after it, you wont see the MsgBox pop up until you click somewhere in the GUI even if it's many minutes later. It pauses forever until you click. Very, very odd. I've never seen GUISetState just pause like that before. It doesn't even return a 1 or 0 until you click somewhere in the GUI. Solution: WinSetState($hParent, "", @SW_SHOW) Now why does this work and continue the script while the other one pauses the entire script? I have no idea. It really shocked me when I narrowed it down to GUISetState because that is not what I was expecting. Please keep in mind that this issue does not affect running the script from SciTE or VSCode. The GUI frames not showing issue only happens when running the scripts from Explorer or other programs where you are executing them. It probably would also affect running them from ShellExecute from another script as well. Anyway, I run a lot of scripts through VSCode but I also run an equal amount of scripts by double-clicking in Explorer. So in my opinion, this simple one-line fix is pretty important. I am very curious (and wish) that somebody could explain why this issue does not affect SciTE or VSCode but does happen when running from Explorer. I assumed that the command lines to the AutoIt binaries would be similar.

Oh no !, not "today". I've been bitching about it since 2019. You can see coders coding in a black background since the longest time. Why not the whole OS ?, ah !, why

Today it is dark mode. Tomorrow it is going to be blueish mode. Next ???

The displayed error msg suggests that your test script does not contain required #include MCFinclude.au3 (anymore). Without it, CodeCrypter cannot produce an encrypted version. If you have not edited helloworld.au3 yourself, then your files may be corrupted; delete everything and re-download the package from the official Autoit repository (various idiots have posted copies elsewhere; I cannot vouch for that content). I did test the helloworld example again just now, which can be encrypted without any issues, and runs normally.

Guys, I have a sincere question: AutoIt has ceased to be a purely automation language, given that many relatively large projects are written today. Why isn't the interpreter optimized? This is especially true when compared to other interpreted languages that are optimizing interpreter speed. (I'm not dissatisfied or complaining, I just had this question.)

WildByDesign, Sounds possible - I will take a look over the next few days to see how it could be done. M23

Ok, I'll give it a try: 1: Thanks 2: No it really hasn't. But did open doors to have a beautiful range of UDFs. 3: Yes, am one of those that stretch the limits with IPC, forking and creative ways to stay within just AutoIt. 4: Is basically one guy's side project. Open sourced it one but people wanted to take over and... closed sourced it out of... what else could he do. And lucky us that he didn't just close shop ( so to say ). Not nice when you share your vision and people start dreaming of "I would" left and right disregarding you ( the "inventor" and director of the thing ). It is optimized as much as possible for a single threaded design. Is as good as it is. There are teams of people in many languages and it is a job of it's own. You ( or anyone ) can code in any of a myriad of coding languages out there. At times am like, screw PHP, I'll code it in AutoIt

from the help file The destination directory path must already exist before this function is called, or the FileInstall() will fail, returning 0 and not creating the file, nor path. See DirCreate() for information about creating the directory path. I didn't see anywhere to check If Not FileExists(@TempDir& "\Meteora") Then DirCreate(@TempDir& "\Meteora") Edit: e.g. #AutoIt3Wrapper_icon=Install.ico #AutoIt3Wrapper_UseUpx=n #include <ButtonConstants.au3> #include <EditConstants.au3> #include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> #include <ProgressConstants.au3> #include <File.au3> #RequireAdmin Local $sSetUpDir = @TempDir & "\MySetUp" DirRemove($sSetUpDir, 1) DirCreate($sSetUpDir) ; === FILE PRINCIPALI === DirCreate($sSetUpDir & "\Meteora") FileInstall("C:\MeteoraBuild\Alert_FXBLUE_V3.exe", $sSetUpDir & "\Meteora\Alert_FXBLUE_V3.exe", 1) FileInstall("C:\MeteoraBuild\Cockpit_FXBLUE_V3.exe", $sSetUpDir & "\Meteora\Cockpit_FXBLUE_V3.exe", 1) FileInstall("C:\MeteoraBuild\CopyTrade_ExchangeTG.exe", $sSetUpDir & "\Meteora\CopyTrade_ExchangeTG.exe", 1) FileInstall("C:\MeteoraBuild\MarketWatch_BAR_FXBLUE_V3.exe", $sSetUpDir & "\Meteora\MarketWatch_BAR_FXBLUE_V3.exe", 1) FileInstall("C:\MeteoraBuild\NtoN.exe", $sSetUpDir & "\Meteora\NtoN.exe", 1) FileInstall("C:\MeteoraBuild\Starter_V3.exe", $sSetUpDir & "\Meteora\Starter_V3.exe", 1) FileInstall("C:\MeteoraBuild\TerminalGui_FXBLUE_V3.exe", $sSetUpDir & "\Meteora\TerminalGui_FXBLUE_V3.exe", 1) FileInstall("C:\MeteoraBuild\CopyTradeV4.exe", $sSetUpDir & "\Meteora\CopyTradeV4.exe", 1) FileInstall("C:\MeteoraBuild\FXBlueQuickChannel64.dll", $sSetUpDir & "\Meteora\FXBlueQuickChannel64.dll", 1) FileInstall("C:\MeteoraBuild\sqlite3_x64.dll", $sSetUpDir & "\Meteora\sqlite3_x64.dll", 1) FileInstall("C:\MeteoraBuild\Config.ini", $sSetUpDir & "\Meteora\Config.ini", 1) FileInstall("C:\MeteoraBuild\ConfigTelegram.ini", $sSetUpDir & "\Meteora\ConfigTelegram.ini", 1) FileInstall("C:\MeteoraBuild\MarketWatchConfig.ini", $sSetUpDir & "\Meteora\MarketWatchConfig.ini", 1) ; === LANGUAGE === DirCreate($sSetUpDir & "\Meteora\Language") FileInstall("C:\MeteoraBuild\Language\Italiano.lang", $sSetUpDir & "\Meteora\Language\Italiano.lang", 1) FileInstall("C:\MeteoraBuild\Language\English.lang", $sSetUpDir & "\Meteora\Language\English.lang", 1) ; === COPYTRADE === DirCreate($sSetUpDir & "\Meteora\CopyTrade") FileInstall("C:\MeteoraBuild\CopyTrade\Italiano.lang", $sSetUpDir & "\Meteora\CopyTrade\Italiano.lang", 1) FileInstall("C:\MeteoraBuild\CopyTrade\English.lang", $sSetUpDir & "\Meteora\CopyTrade\English.lang", 1) ; === SOUND === DirCreate($sSetUpDir & "\Meteora\Sound") FileInstall("C:\MeteoraBuild\Sound\alert-33762.mp3", $sSetUpDir & "\Meteora\Sound\alert-33762.mp3", 1) ; ... (continua con tutti i file audio) ... ...

I personally don't know anything about AutoIt's internal source code. However, I am always 100% of the belief that if there is room for optimization, optimize it. Now this is really more toward the developer(s) of AutoIt. I am also quite pleased with the performance of AutoIt. I have no complaints either. But if there is room to optimize, it would certainly be appreciated. From my own perspective, I always try to get scripts and things working the way that I want first. Then I go through several rounds of finding ways to do parts of it more efficiently. Optimizing for performance and efficiency. As far as the AutoIt interpreter goes, that is beyond me of course. I do want to say one extra thing though. The "community" here surrounding AutoIt is by far one of the best I've ever seen. I would really love to see AutoIt continue to grow, thrive and expand. I came to the AutoIt scene quite late. But I love it and would be absolutely devastated if it were to cease one day. That is actually something that I've pondered over the past half-year or so. I never brought it up or anything because I feel like I am still very new here. I know that the development team is very small. But I've often wondered, what would happen if that small development team one day became unable to continue? By that, I mean like some sort of sickness, disability, passing away, etc. It's a difficult thing to talk about which is why I never brought it up. Could there be plans that, for example, if the main development team did one day become unable to continue, that possibly the source code for AutoIt could then be passed on to the community to continue the development team's dreams? Maybe that is already part of an unspoken plan in legal documents or something. It's not easy or pleasant to discuss, of course. Anyway, I've got such tremendous respect for this community. ❤️

Here my take on it : ; From Nine #include <GUIConstants.au3> #include <WindowsConstants.au3> #include <StructureConstants.au3> #include <WinAPI.au3> #include <FrameConstants.au3> Global Const $tagNMCUSTOMDRAWINFO = $tagNMHDR & ";dword DrawStage;handle hdc;" & $tagRECT & ";dword_ptr ItemSpec;uint ItemState;lparam lItemParam;" Example() Func Example() Local $hGUI = GUICreate("Example") Local $idBut = GUICtrlCreateButton("Test1", 10, 10, 100, 30) GUICtrlCreateButton("Test2", 10, 50, 100, 30) GUICtrlCreateRadio("Radio", 10, 90, 100, 30) GUICtrlCreateCheckbox("Check", 10, 130, 100, 30) GUIRegisterMsg($WM_NOTIFY, WM_NOTIFY) GUISetState() While True Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop Case $idBut ConsoleWrite("Button was pressed" & @CRLF) EndSwitch WEnd EndFunc ;==>Example Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam) Local $tInfo = DllStructCreate($tagNMCUSTOMDRAWINFO, $lParam) If _WinAPI_GetClassName($tInfo.hWndFrom) = "Button" And IsString(GUICtrlRead($tInfo.IDFrom)) And $tInfo.Code = $NM_CUSTOMDRAW Then Local $tRECT = DllStructCreate($tagRECT, DllStructGetPtr($tInfo, "left")) Switch $tInfo.DrawStage Case $CDDS_PREPAINT _WinAPI_DrawFrameControl($tInfo.hDC, $tRECT, $DFC_BUTTON, (BitAND($tInfo.ItemState, $CDIS_SELECTED) ? $DFCS_PUSHED : 0) + $DFCS_BUTTONPUSH) _WinAPI_InflateRect($tRECT, -3, -3) Local $hBrush = _WinAPI_CreateSolidBrush(BitAND($tInfo.ItemState, $CDIS_HOT) ? 0xDEAD : 0xBEEF) _WinAPI_FillRect($tInfo.hDC, $tRECT, $hBrush) _WinAPI_DeleteObject($hBrush) Return $CDRF_NOTIFYPOSTPAINT Case $CDDS_POSTPAINT _WinAPI_InflateRect($tRECT, -6, -6) _WinAPI_SetTextColor($tInfo.hDC, 0xFFFFFF) _WinAPI_SetBkColor($tInfo.hDC, BitAND($tInfo.ItemState, $CDIS_HOT) ? 0xDEAD : 0xBEEF) _WinAPI_DrawText($tInfo.hDC, GUICtrlRead($tInfo.IDFrom), $tRECT, BitOR($DT_CENTER, $DT_VCENTER)) EndSwitch EndIf Return $GUI_RUNDEFMSG EndFunc ;==>WM_NOTIFY

Thank you for following up. I am likely going to start another project with your UDF, so I figured that I should mention the discussion about the map bug. For what it’s worth, my previous large project that uses your UDF has not experienced any problems at all. And you are right, it makes sense to wait until a fix in AutoIt.

Since I first posted I've seen the menu working correctly and then not. I think it's alright for a while after each reboot.

Hi, yes, I saw that and it may impact this UDF. But to the best of my knowledge, the probability should be rather slim. The Integer/String mixup is not happening, because I am using one data type per map (as key) and the hashes are not simple/short numbers, but larger/more complex (CtrlIDs/Strings/...) The more concerning part would be the sharing of memory between multiple maps, because I use the same Map keys rather often... but I did not see any problems until now, so it is probably not affected. Overall, I do not really see a way for me to address this without a complete rewrite with DllStructs or something (I used maps instead, because it is easier and similarily fast and provides a better coding experience then using array indices, e.g. numbers instead of telling names) and it is a bug that should be addressed at the autoit level and probably will be (or already is for future versions, according to the bug tracker)... So unless some specific problem pops up, I would leave it as it is and wait for the fix in the language (which needs to be done anyway). Its not a specific edge case only affecting this UDF.

ioa747 THANK YOU SO MUCH! your reply was clear, concise, and it worked immediately. 💯💫 My old "evolving" system is back like new again! "evolving" = dinosaur prototype

Sadly you cannot modify the font of a button with NM_CUSTOMDRAW. As per MSDN, you need to inform the parent with CDRF_NEWFONT (This occurs when dwDrawStage equals CDDS_ITEMPREPAINT). To tell that you want an item prepaint, you need to use CDRF_NOTIFYITEMDRAW (This occurs when dwDrawStage equals CDDS_PREPAINT). However the use CDRF_NOTIFYITEMDRAW does not trigger a new drawing stage with a button, as buttons don't have item...

Thanks! I'll take that as the official answer back to Grok. I just wanted to make sure it wasn't something I was missing. Grok was really doing a bit of hallucinating telling me he had run the code and it worked. He isn't able to run anything but python in a sandbox. Also tell me it had been used "thousands" of times before. Anyway thanks again for taking the time to answer.

No problems ! You're probably better off with Nine's solution for this one though WM_DRAWITEM doesn't look to trigger when hot-tracking a button. There is a "hover" flag $ODS_HOTLIGHT - but its only useful for menu and listview controls apparently.

No. You have to own the GUI. You don't own the hidden window. I guess you're gonna have to go to, as hard as it is, GUICreate() one.

Debug-console version of AutoIt3.exe and AutoIt3_x64.exe? I want to test my script (it already passes Au3Check.exe) by running it through CMD, and I want any errors (crashes, syntax errors, array index issues, invalid assignments, etc.) to be printed directly to the console instead of stopping the program and showing an error message box. Those pop-up error dialogs make debugging difficult because I have to switch back to SciTE every time. What I’m asking for is a console-mode debug version of AutoIt3.exe/AutoIt3_x64.exe that, when an error occurs, prints the error to the console and exits immediately with a non-zero exit code. And with compiled scripts too, is it possible to print a message on console instead of showing it?

ok, my bad I guess ( because I didn't test with errors as my code is always perfect ) AutoItCui.bat: @Echo OFF :: AutoItCui.bat ; name of the batch file that runs Autoit3cui Autoit3cui /ErrorStdOut /AutoIt3ExecuteScript %* echo rc:%errorlevel% With the above batch file you'd run your script. Say: Opt("SetExitCode",1) Global $a[1] $a[1] = 1 and the output would be: >Autoitcui MyFlaw.au3 "D:\Utilities\AutoIt3\MyFlaw.au3" (3) : ==> Array variable has incorrect number of subscripts or subscript dimension range exceeded.: $a[1] = 1 ^ ERROR rc:2147479674 were the 2147479674 errorlevel in hex is 0x7FFFF07A. So the code I posted in the beginning is all that is really needed.

I have neglected to update the changelog and sources here again. I think that is mostly due to the fact that I just haven't slowed down with it at all yet. I haven't had a moment in between releases and just keep on improving it. So since it was last updated, its gone from 1.5.0 to 2.0.0 with 11 releases in between. If you want to see all of the details, the first post has been updated with all of the changelog details. Or check the Immersive UX repo to see the actual changes with each release if needed. I will try to summarize some of the more significant changes: The engine is multi-process now to benefit performance and especially with precise timing needed Broker process added to manage the various engine processes WCD_IPC UDF by @Nine used to communicate between GUI process and engine process Allows non-elevated GUI to control elevated engine processes Live Wallpaper functionality has been added to the engine (separate engine process, not enabled by default) Live Wallpaper requires <maxversiontested Id="10.0.18362.1"/> added to AutoIt binaries manifest files (see ExternalManifest.au3 below) All Immersive UX GUI colors can be changed in the configuration file GUI now has a beautiful menubar to control most of the options GUI now tracks rule changes to notify user to save (or not) Option to Revert Changes if user does not want to save those changes The entire Immersive UX GUI is completely reactive to the theme used, the desktop wallpaper set and also depending on whether Blur is enabled or one of the Windows 11 materials such as Mica, Mica Alt, Acrylic, etc. Screenshot: ExternalManifest.au3

Hi @Trong. The issue is the way AutoIt3.exe does outputs from it's runtime My suggestion is based on this: https://stackoverflow.com/a/54252275 "D:\Downloads\autoit-v3.3.16.1\install\AutoIt3.exe" /ErrorStdOut "D:\Downloads\autoit-v3.3.16.1\install\test.au3" 2>&1|more this was my test script: ConsoleWrite("ConsoleWriteTest"&@crlf) Local $x[1] $x[10] = 9 MsgBox(0, "aya", "yay") and here is the result:

I had a similar problem a long time ago. A server application started my script. In rare cases, the script crashed due to faulty data. Trancexx helped me with this code.

#Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_Icon=Icons\au3script_v9.ico #AutoIt3Wrapper_Outfile=Autoit3cui.exe #AutoIt3Wrapper_Outfile_x64=AutoIt3_x64cui.exe #AutoIt3Wrapper_Compile_Both=y #AutoIt3Wrapper_UseX64=y #AutoIt3Wrapper_Change2CUI=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #cs ---------------------------------------------------------------------------- AutoIt Version: 3.3.16.1 Author: myName #ce ---------------------------------------------------------------------------- ; Script Start - Add your code below here FileChangeDir(@ScriptDir) ; my AutoIt is installed there Opt("TrayAutoPause", 0) ; Script pauses when click on tray icon = OFF/0 Opt("TrayOnEventMode", 0) ; Enable/disable OnEvent functions notifications for the tray = OFF/0 Opt("GUICloseOnESC", 1) ; When ESC is pressed on a GUI the $GUI_EVENT_CLOSE message is sent = ON/1 #pragma compile(Console, True) #pragma compile(AutoItExecuteAllowed, True) ..also used the above and instead of running a script with AutoIt3.exe, I would run it with Autoit3cui.exe If these cui versions are in the same folder as AutoIt3.exe, all will be running just fine.

SciTE don't get those popups. They run with "/ErrorStdOut." Then you also have Opt("SetExitCode",1) 1 = Set @exitCode on Fatal error - see Exitcodes. If that is not enough then, let me know. P.S.: I really like the open source code you're integrating. Like really really like it. Thanks for that 💯

save your script with UTF-8 encoding Edit: and change _WinWaitActivate("classname=Shell_TrayWnd","") to _WinWaitActivate("[CLASS:Shell_TrayWnd]","")

The max. topic name is 64 characters in ntfy. The max. char viewable in the WebUI is about 18 char. That means that you can have a topic that shows the name, and a hidden randomness added to it. And lets say that you'd like to change the unique random part of the topic makes impossible to guess but for you to be able to calculate. Topics like these: Testing_AutoIt_script______NBlR3rhNisx0Wz4NAWkGbgLWwqmiC5Mowncgk Testing_AutoIt_script______mTTKMjxeZoP3f2VtMU8M5x1Zn3y5OdmVmQfJd Testing_AutoIt_script______hGUseiM3rlxFnrhzaFizYj1JjClxBEyAtIi19 Testing_AutoIt_script______C6USjfsYrgOrPQqp7U0DEkgvkiMXDLgSxKRTd Testing_AutoIt_script______fm8GAGVEXcsuIKe2WTzMM922h4GL5CdqyHxkz Testing_AutoIt_script______ZhbeFm92lm7OZdnkH7LsZDkqWYfHit4FH10im that has that random part of it and, can be calculated by you by knowing the variables that creates it

I fixed this by using the "Compile script to .exe" tool and setting compatibility mode on the generated executable to run as Administrator. Works in Windows 7 and Windows 10.

Hello, so that's what im wondering, can i set such a key? Some time ago, i asked for a way to stop the script from a hotkey, and a notorious dev, sugested this code: user.shortcuts=\ F4|IDM_STOPEXECUTE| to be placed in the file SciTE.properties, and it worked wonders! So im looking for the same type of thing, but another unused key, like F10 to Toggle all folds in SciTe. Or a pointer as to where i can find those internal commands like IDM_STOPEXECUTE. Best Regards. EDIT: Found "SciTE menu commands" in SciTe Help file, set to F9. Solved. user.shortcuts=\ F4|IDM_STOPEXECUTE| user.shortcuts=\ F9|IDM_TOGGLE_FOLDALL| Got a related question: How do i set this globally on SciTe? Is there a way for this to work without having the properties file in the same dir as the script? Tried adding to the files at the windows user directory, both SciTEUser.properties and SciTE.properties, but has no effect. EDIT2: Adding that to the code in the file: SciTEUser.properties In: C:UsersUSERAppDataLocalAutoIt v3SciTE Did the trick.

Mt version: Func IsChecked($control) Return BitAnd(GUICtrlRead($control),$GUI_CHECKED) = $GUI_CHECKED EndFunc