Jump to content

Recommended Posts

Posted

Example: Something similar to GUICtrlSetStyle to add (or remove) extended style $WS_EX_COMPOSITED to File Explorer's (explorer.exe) treeview (SysTreeView32).

Here is what I have so far:

#include <Array.au3>
#include <MsgBoxConstants.au3>
#include <WinAPIDlg.au3>
#include <WindowsConstants.au3>

Example()

Func Example()
        Local $aWinList = WinList("This PC - File Explorer")
        ;_ArrayDisplay($aWinList)
        ConsoleWrite($aWinList[1][1] & @CRLF)
        $hWnd = $aWinList[1][1]
        ;GUICtrlSetStyle($hWnd, -1, $WS_EX_COMPOSITED)
        ;MsgBox($MB_SYSTEMMODAL, "ID", "Dialog Control ID: " & _WinAPI_GetDlgCtrlID($hWnd))
        ControlMove($hWnd, "", "[CLASS:SysTreeView32]", 0, 0, 150, 150)
EndFunc   ;==>Example

The only purpose of the ControlMove function is to show me visually that I've got the right handle for explorer.exe and the right class. But that is far as I can get.

Is there any way to set the extended style for the SysTreeView32 control of another process (explorer.exe)?

Thank you for your time.

Posted (edited)
Instance: [CLASS:DirectUIHWND; INSTANCE:2]
Style: WS_CHILD, WS_VISIBLE, WS_CLIPSIBLINGS, WS_CLIPCHILDREN
ExStyle: 0x000000

DirectUIHWND is not SysTreeView32 :(
I don't know if that technic will work on Win11 ( haven't tested either )

Edit: Oops. I meant the ListView side. 🤪

Edited by argumentum
oops

Follow the link to my code contribution ( and other things too ).
FAQ - Please Read Before Posting.
autoit_scripter_blue_userbar.png

Posted
7 minutes ago, argumentum said:

don't know if that technic will work on Win11 ( haven't tested either )

Also I just found this msdn link which stipulates :

The SetWindowLongPtr function fails if the process that owns the window specified by the hWnd parameter is at a higher process privilege in the UIPI hierarchy than the process the calling thread resides in.

 

"I think you are searching a bug where there is no bug... don't listen to bad advice."

Posted
9 minutes ago, argumentum said:

DirectUIHWND is not SysTreeView32

..I made a mistake there, pointing that out. That wasn't the OP question  =/

4 minutes ago, pixelsearch said:
... if the process that owns the window specified by the hWnd parameter is at a higher process privilege ...

Yes, that's a given. Unless as admin won't work either ? ( no time to test, playing around with something else )

Follow the link to my code contribution ( and other things too ).
FAQ - Please Read Before Posting.
autoit_scripter_blue_userbar.png

Posted

@WildByDesign   If you're sure that the requested window got the $WS_EX_COMPOSITED extended style set, then you can try this :

Local $hWnd = ...
Local $iExStyle = _WinAPI_GetWindowLong($hWnd, $GWL_EXSTYLE)
Local $iExStyleToRemove = $WS_EX_COMPOSITED

If BitAND($iExStyle, $iExStyleToRemove) = $iExStyleToRemove Then
    _WinAPI_SetWindowLong($hWnd, $GWL_EXSTYLE, BitXOR($iExStyle, $iExStyleToRemove))
Endif

 

"I think you are searching a bug where there is no bug... don't listen to bad advice."

Posted
5 minutes ago, pixelsearch said:

If you're sure that the requested window got the $WS_EX_COMPOSITED extended style set, then you can try this :

Thanks for the suggestions. It seems like the perfect function for what I'm trying to do. I'm using System Informer (previously Process Hacker) to view all of the details about various windows and controls. After running the initial code snippet that you shared, I could not see any change in the extended styles in System Informer. It could be because File Explorer may have more protections against this sort of thing. I'm not sure yet.

It did get File Explorer firing up the CPU quite a lot, so it definitely did something. I have to spend more time looking into it.

The reason why I am trying this is because some users have suggested that when applying full window Acrylic or Mica, the composited extended style is supposed to make the text in the treeview sharper.

Posted
32 minutes ago, pixelsearch said:

Also I just found this msdn link which stipulates :

This also:

Certain window data is cached, so changes you make using SetWindowLongPtr will not take effect until you call the SetWindowPos function.

I will have to consider this as well and dig into this more later.

  • Solution
Posted (edited)

I use something like this in SMF internally, not tested on other processes.

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

Local $hGUI = GUICreate("Example", 400, 400)
GUISetState(@SW_SHOW, $hGUI)

Sleep(1000)
__WinAPI_Set_Window_Style($hGUI, $WS_SIZEBOX, True, False)
Sleep(5000)
__WinAPI_Set_Window_Style($hGUI, $WS_SIZEBOX, False, False)
Sleep(1000)
__WinAPI_Set_Window_Style($hGUI, $WS_EX_TOOLWINDOW, True, True)
Sleep(5000)
__WinAPI_Set_Window_Style($hGUI, $WS_EX_TOOLWINDOW, False, True)

While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            ExitLoop
    EndSwitch
WEnd

Func __WinAPI_Set_Window_Style($hWnd, $i_Style, $b_Add, $b_exStyle = False)

    If $b_exStyle = False Then
        Local $i_Style_Old = _WinAPI_GetWindowLong($hWnd, $GWL_STYLE)
    Else
        Local $i_Style_Old = _WinAPI_GetWindowLong($hWnd, $GWL_EXSTYLE)
    EndIf

    If $b_Add Then ; Style already applied
        If BitAND($i_Style_Old, $i_Style) Then Return
    Else ; Style not set
        If Not BitAND($i_Style_Old, $i_Style) Then Return
    EndIf

    If $b_exStyle = False Then
        If $b_Add Then
            _WinAPI_SetWindowLong($hWnd, $GWL_STYLE, BitOR($i_Style_Old, $i_Style))
        Else
            _WinAPI_SetWindowLong($hWnd, $GWL_STYLE, BitXOR($i_Style_Old, $i_Style))
        EndIf
    Else
        If $b_Add Then
            _WinAPI_SetWindowLong($hWnd, $GWL_EXSTYLE, BitOR($i_Style_Old, $i_Style))
        Else
            _WinAPI_SetWindowLong($hWnd, $GWL_EXSTYLE, BitXOR($i_Style_Old, $i_Style))
        EndIf
    EndIf

    _WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE))

EndFunc   ;==>__WinAPI_Set_Window_Style

 

Edited by KaFu
Posted
1 hour ago, KaFu said:

I use something like this in SMF internally, not tested on other processes.

Thank you for sharing this, very helpful. Especially the arguments for _WinAPI_SetWindowPos were very important and I had no idea what arguments I should try at first.

Posted
On 5/18/2025 at 1:16 AM, WildByDesign said:

Also I just found this msdn link which stipulates :

Certain window data is cached, so changes you make using SetWindowLongPtr will not take effect until you call the SetWindowPos function. 

I will have to consider this as well and dig into this more later.

Hello, just curious. Have you found a solution to your initial question ?
In case @KaFu's function is part of the solution, could you please confirm that it works only when _WinAPI_SetWindowPos is present ?

Thanks :)

"I think you are searching a bug where there is no bug... don't listen to bad advice."

Posted
1 hour ago, pixelsearch said:

Hello, just curious. Have you found a solution to your initial question ?
In case @KaFu's function is part of the solution, could you please confirm that it works only when _WinAPI_SetWindowPos is present ?

First, thank you for your help with this. I appreciate it very much.

So technically it did not fix the situation that I was working with. It didn't end up being as simple as removing (or adding) WS_EX_COMPOSITED to/from the extended styles. I was hoping it would be that easy.

It ended up being COMPOSITED being added through msstyles (theming file) and not being added during process init. I don't think that we have any way to intercept the underlying msstyles functionality.

As far as whether or not the solution works for adding/removing extended styles from other processes in general, that did work. Some processes don't allow it though depending on other circumstances.

Whether or not it required _WinAPI_SetWindowPos also depended on circumstances. Sometimes it was needed and sometimes not. I don't understand it fully but I believe it had something to do with whether or not the process cached styles or not.

Posted

@WildByDesign thanks for your last detailed explanations !

4 hours ago, WildByDesign said:

Whether or not it required _WinAPI_SetWindowPos also depended on circumstances. Sometimes it was needed and sometimes not.

I found a problem when using Kafu's function, let me explain it.
First of all, I like his function because it allows to solve any of the 4 scenarios : add (or remove) a style (or extended style) inside a single function.

Now let's say we would like to use his function, not only for top-level windows, but also for child windows (like gui controls) . Here is a runnable script that allows it :

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

Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration

Local $hGUI = GUICreate("Example", 250, 220)
Local $idRadio[4]

GUICtrlCreateGroup(" Group ", 30, 10, 190, 130)
For $i = 1 To 4
    $idRadio[$i - 1] = GUICtrlCreateRadio("Radio " & $i, 40, 25 * $i, 150, 25)
Next
GUICtrlCreateGroup("", -99, -99, 1, 1)

Local $idButton_OK = GUICtrlCreateButton("OK", 35, 170, 75, 25)
Local $idButton_Cancel = GUICtrlCreateButton("Cancel", 140, 170, 75, 25)

GUISetState(@SW_SHOW, $hGUI)

Local $nMsg
While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            ExitLoop
        Case $idRadio[0] To $idRadio[3]
            __WinAPI_Set_Window_Style(GUICtrlGetHandle($nMsg), $WS_TABSTOP, False)
    EndSwitch
WEnd

;==============================================
Func __WinAPI_Set_Window_Style($hWnd, $i_Style, $b_Add, $b_exStyle = False)

    If $b_exStyle = False Then
        Local $i_Style_Old = _WinAPI_GetWindowLong($hWnd, $GWL_STYLE)
    Else
        Local $i_Style_Old = _WinAPI_GetWindowLong($hWnd, $GWL_EXSTYLE)
    EndIf

    If $b_Add Then ; Style already applied
        If BitAND($i_Style_Old, $i_Style) Then Return
    Else ; Style not set
        If Not BitAND($i_Style_Old, $i_Style) Then Return
    EndIf

    If $b_exStyle = False Then
        If $b_Add Then
            _WinAPI_SetWindowLong($hWnd, $GWL_STYLE, BitOR($i_Style_Old, $i_Style))
        Else
            _WinAPI_SetWindowLong($hWnd, $GWL_STYLE, BitXOR($i_Style_Old, $i_Style))
        EndIf
    Else
        If $b_Add Then
            _WinAPI_SetWindowLong($hWnd, $GWL_EXSTYLE, BitOR($i_Style_Old, $i_Style))
        Else
            _WinAPI_SetWindowLong($hWnd, $GWL_EXSTYLE, BitXOR($i_Style_Old, $i_Style))
        EndIf
    EndIf

    _WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE)) ; Kafu's original line
    ; _WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE, $SWP_NOZORDER))

EndFunc   ;==>__WinAPI_Set_Window_Style

Unfortunately, if you run this script and start clicking on the radio buttons, then you should see this the 1st time you click on them, i.e. the 4 buttons can be checked at same time !

4radiobuttonscheckedatsametime.png.76884f192538f41d20549bc522c158d8.png

If you run AutoIt Window Info after you checked a radio button, then you should not see this correct behavior :

AutoItWindowInfopicksRadio1.png.fd8fd20ecd6338986fc856d5d1f87080.png

imho this issue comes from the fact that the Z-order of the 4 radio buttons became a mess, as indicated by a NirSoft utility named GuiPropView :

...Z-ordershouldnotchange.png.4a57bea747d119d2c6577315422adb77.png

Now let's focus on this line :

_WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE)) ; Kafu's original line

For a start, If we comment out this line and run the script again, then everything goes back to normal.

Now let's go check msdn, which stipulates what follows in its SetWindowPos link ;

If you have changed certain window data using SetWindowLong, you must call SetWindowPos for the changes to take effect. Use the following combination for uFlags: SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED.

See how they included SWP_NOZORDER in the arguments ?
Which is described as "Retains the current Z order (ignores the hWndInsertAfter parameter)"

Now if we add SWP_NOZORDER to Kafu's line and run the script again, then everything goes fine because the controls Z-order will not change after you click on them.

You'll find a reworked _WinAPI_SetWindowPos line in the script (under Kafu's original line) so you can try it from there, after commenting out / uncommenting the line you'd like to test :

_WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE)) ; Kafu's original line

; _WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE, $SWP_NOZORDER))

Hope you'll find this test useful :)

"I think you are searching a bug where there is no bug... don't listen to bad advice."

Posted (edited)
On 5/20/2025 at 10:46 PM, KaFu said:

I use something like this in SMF internally, not tested on other processes.

Glad you enjoyed the previous test :)

I just tried your function on 2 different processes and it worked fine.

1) 1st process : please launch this 1st script and don't close its GUI :

#include <GUIConstantsEx.au3>

Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration

Local $hGUI = GUICreate("Try to make a GUI resizable from external process", 500, 250) ; do not change this title
GUISetState(@SW_SHOW, $hGUI)

While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            ExitLoop
    EndSwitch
WEnd

2) 2nd process : now launch this 2nd script, then click the button to add a $WS_SIZEBOX style to the GUI from 1st script :

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

Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration

Local $sTitle = "Try to make a GUI resizable from external process" ; do not change this title

Local $hGUI = GUICreate("The external process", 250, 220)
Local $idButton = GUICtrlCreateButton("Add Resize style to external GUI", 25, 170, 200, 25)

GUISetState(@SW_SHOW, $hGUI)

While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            ExitLoop
        Case $idButton
            If Not WinExists($sTitle) Then
                MsgBox($MB_TOPMOST, "External GUI not found, named...", Chr(34) & $sTitle & Chr(34))
            Else
                Local $hWndExternal = WinGetHandle($sTitle) ; external GUI
                If @error Then Exit MsgBox($MB_TOPMOST, "Impossible WinGetHandle error", "@error = " & @error)
                __WinAPI_Set_Window_Style($hWndExternal, $WS_SIZEBOX, True)
                MsgBox($MB_TOPMOST, "Please check", "External GUI should be resizable by now")
            EndIf
    EndSwitch
WEnd

;===========================================
Func __WinAPI_Set_Window_Style($hWnd, $i_Style, $b_Add, $b_exStyle = False) ; compacted code (from Kafu's original)

    If Not IsHWnd($hWnd) Then $hWnd = GUICtrlGetHandle($hWnd)
    Local $iIndex = $b_exStyle ? $GWL_EXSTYLE : $GWL_STYLE ; $iIndex as named by msdn & help file
    Local $i_Style_Old = _WinAPI_GetWindowLong($hWnd, $iIndex)

    If $b_Add Then
        If BitAND($i_Style_Old, $i_Style) Then Return ; style already applied
        _WinAPI_SetWindowLong($hWnd, $iIndex, BitOR($i_Style_Old, $i_Style))
    Else ; remove
        If Not BitAND($i_Style_Old, $i_Style) Then Return ; style not set
        _WinAPI_SetWindowLong($hWnd, $iIndex, BitXOR($i_Style_Old, $i_Style))
    EndIf

    _WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE, $SWP_NOZORDER)) ; +++

EndFunc   ;==>__WinAPI_Set_Window_Style

I also did this kind of test on an Explorer window (this time to remove its $WS_SIZEBOX style) and it worked. I'll try the test on the Explorer window on a Windows 11 OS in a couple of days and will report here if it worked or not :bye:

Edited by pixelsearch
typo

"I think you are searching a bug where there is no bug... don't listen to bad advice."

Posted
15 hours ago, pixelsearch said:

See how they included SWP_NOZORDER in the arguments ?

Excellent find!

5 hours ago, pixelsearch said:

I also did this kind of test on an Explorer window (this time to remove its $WS_SIZEBOX style) and it worked.

You have an excellent style for teaching. I know that making examples, testing and creating example images and so on all takes time and I appreciate the time that you put into it. Your examples are easy to test and therefore easy to understand. I personally can say that I benefit very well from your style of teaching. Thank you for that.

I'm glad that you tested on Explorer as well and had success. All of your extra finding here have got me interested in testing this more now because I feel like there are other circumstances where these methods with come in handy.

Posted

So I've spent some more time trying to either add or remove extended styles specifically from Explorer's SysTreeView32 control but still no success adding or removing. Quite often it ends up causing Explorer to max out CPU usage on one core. Closing and reopening the Explorer window is enough to fix that.

I can successfully add or remove extended styles to Explorer's main GUI handle. But not for a specific control as SysTreeView32 which is what I am testing right now.

I use ControlMove just to resize the SysTreeView32 control in Explorer just as a visual test to see that I've got the right control handle.

Current example:

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

Example()

Func Example()
        Local $aWinList = WinList("This PC - File Explorer")
        ;_ArrayDisplay($aWinList)
        ConsoleWrite($aWinList[1][1] & @CRLF)
        $hWnd = $aWinList[1][1]
        ; get handle for systreeview32
        Local $hControl = ControlGetHandle($hWnd, "[CLASS:SysTreeView32]", "")
        Local $hControl1 = ControlGetHandle($hWnd, "[CLASS:Static]", "")
        Local $hControl2 = ControlGetHandle($hWnd, "[CLASS:NamespaceTreeControl]", "")
        ConsoleWrite($hControl & @CRLF)
        
        ;_WinAPI_SetWindowLong($hControl, $GWL_EXSTYLE, $WS_EX_COMPOSITED)
        
        ;#cs
        Local $WS_EX_VISIBLEWHENOTGHOSTED = 0x00000800
        Local $iExStyle = _WinAPI_GetWindowLong($hWnd, $GWL_EXSTYLE)
        Local $iExStyleToRemove = $WS_EX_VISIBLEWHENOTGHOSTED

        If BitAND($iExStyle, $iExStyleToRemove) = $iExStyleToRemove Then
        _WinAPI_SetWindowLong($hWnd, $GWL_EXSTYLE, BitXOR($iExStyle, $iExStyleToRemove))
        Endif
        ;#ce

        ; modify treeview size just to show that it is right handle
        ControlMove($hWnd, "", "[CLASS:SysTreeView32]", 0, 0, 150, 150)

        _WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE, $SWP_NOZORDER))

        ; try to just refresh systreeview32 only
        _WinAPI_SetWindowPos($hControl, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE, $SWP_NOZORDER))
EndFunc   ;==>Example

I was testing with classes CLASS:Static and CLASS:NamespaceTreeControl because they are controls that surround (or hold) the SysTreeView32 control but those did not prove to be useful.

Posted

- ..is like WTF !.
- Language please !
- ..but the MF won't change !
- What I mean by language is, win32 vs .NET or other languages. Everyone knows what "Hola" mean but does not mean you speak Spanish, same with ciao ( Italian ). The point is that explorer is not win32. You'd benefit from looking at it from maybe C# or the like.

Thank you for reading this excerpt from the upcoming novel "I can hear but don't understand". A book about one thing or another by renown book writer @argumentum coming to an amason near you, in PDF, later this year decade century

Follow the link to my code contribution ( and other things too ).
FAQ - Please Read Before Posting.
autoit_scripter_blue_userbar.png

Posted (edited)
6 hours ago, WildByDesign said:

You have an excellent style for teaching. I know that making examples, testing and creating example images and so on all takes time and I appreciate the time that you put into it. Your examples are easy to test and therefore easy to understand. I personally can say that I benefit very well from your style of teaching. Thank you for that.

Thanks a lot for the kind words :)
I once did write nearly the same to @Melba23 . I always thought he was a teacher in real life but he assured me he wasn't. I learned a lot from his examples, since day 1, not only from his technical skills but also from his way of exposing the examples and his clear & detailed explanations.

Now back to your first question :

On 5/17/2025 at 11:32 PM, WildByDesign said:

How to add (or remove) extended style $WS_EX_COMPOSITED to File Explorer's (explorer.exe) treeview (SysTreeView32) ?

I succeeded right now with the following code on my computer, but you'll have to wait a couple of days so I'll test the code on a Windows 11 computer (maybe it won't work on Win11 ?)

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

Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration

Local $sTitle = "G:\Temp" ; Windows explorer opened on "G:\Temp" <============ Change this line to suit your Windows Explorer

Local $hGUI = GUICreate("The external process 3", 250, 220)

Local $idButton_Add = GUICtrlCreateButton("Add $WS_EX_COMPOSITED" & @crlf & _
    "To SysTreeView32 in Explorer", 25, 40, 200, 50, 0x2000) ; $BS_MULTILINE = 0x2000

Local $idButton_Remove = GUICtrlCreateButton("Remove $WS_EX_COMPOSITED" & @crlf & _
    "From SysTreeView32 in Explorer", 25, 130, 200, 50, 0x2000)

GUISetState(@SW_SHOW, $hGUI)

Local $nMsg
While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            ExitLoop

        Case $idButton_Add, $idButton_Remove
            If Not WinExists($sTitle) Then
                MsgBox($MB_TOPMOST, "Explorer title not found, named...", Chr(34) & $sTitle & Chr(34))
            Else
                Local $hWndExternal = WinGetHandle($sTitle) ; Explorer
                If @error Then Exit MsgBox($MB_TOPMOST, "Impossible WinGetHandle error", "@error = " & @error)

                Local $hControl = ControlGetHandle($hWndExternal, "", "[CLASS:SysTreeView32]")
                If @error Then Exit MsgBox($MB_TOPMOST, "Explorer SysTreeView32", "its handle wasn't retrieved") ; possible ?
                ; ConsoleWrite($hControl & @crlf)

                __WinAPI_Set_Window_Style($hControl, $WS_EX_COMPOSITED, _
                    ($nMsg = $idButton_Add ? True : False), _ ; add or remove...
                    True) ; True = ...the extended style

                MsgBox($MB_TOPMOST, "Please check Explorer TreeView (with AutoIt Window Info)", _
                    "It should now have the extended style $WS_EX_COMPOSITED " & _
                    ($nMsg = $idButton_Add ? "set" : "UNset"))
            EndIf
    EndSwitch
WEnd

;===========================================
Func __WinAPI_Set_Window_Style($hWnd, $i_Style, $b_Add, $b_exStyle = False) ; compacted code (from Kafu's original)

    If Not IsHWnd($hWnd) Then $hWnd = GUICtrlGetHandle($hWnd)
    Local $iIndex = $b_exStyle ? $GWL_EXSTYLE : $GWL_STYLE ; $iIndex as named by msdn & help file
    Local $i_Style_Old = _WinAPI_GetWindowLong($hWnd, $iIndex)

    If $b_Add Then
        If BitAND($i_Style_Old, $i_Style) Then Return ; style already applied
        _WinAPI_SetWindowLong($hWnd, $iIndex, BitOR($i_Style_Old, $i_Style))
    Else ; remove
        If Not BitAND($i_Style_Old, $i_Style) Then Return ; style not set
        _WinAPI_SetWindowLong($hWnd, $iIndex, BitXOR($i_Style_Old, $i_Style))
    EndIf

    Local $iRet = _WinAPI_SetWindowPos($hWnd, $HWND_TOP, 0, 0, 0, 0, BitOR($SWP_FRAMECHANGED, $SWP_NOACTIVATE, $SWP_NOMOVE, $SWP_NOSIZE, $SWP_NOZORDER)) ; +++
    If Not $iRet Then MsgBox($MB_TOPMOST, "_WinAPI_SetWindowPos", "Error = " & _WinAPI_GetLastError() & "   Message = " & _WinAPI_GetLastErrorMessage())

EndFunc   ;==>__WinAPI_Set_Window_Style

Clicking on one of the 2 buttons from the GUI should set/unset the $WS_EX_COMPOSITED extended style to/from the SysTreeView32 control of Explorer :

Add-RemoveanextendedstyletoWindowsExplorer.png.366ab2262cff61ed45d7e63984ea8884.png

Just after clicking the Add button, if you check with "AutoIt Window Info" then you hopefully will see that the ExStyle of the SysTreeView32 control has changed from 0 to 0x02000000 (it changes on my computer) :

$WS_EX_COMPOSITED = 0x02000000

SysTreeView32 :
ExStyle: 0x00000000 (when $WS_EX_COMPOSITED not set)
ExStyle: 0x02000000 (when $WS_EX_COMPOSITED set)

Before running the script, just modify this line...

Local $sTitle = "G:\Temp" ; Windows explorer opened on "G:\Temp" <============ Change this line to suit your Windows Explorer

...and indicate the title that corresponds to your Explorer (you indicated in one of your scripts "This PC - File Explorer")

Good luck & fingers crossed :bye:

Edited by pixelsearch
typo

"I think you are searching a bug where there is no bug... don't listen to bad advice."

Posted
1 hour ago, pixelsearch said:

I succeeded right now with the following code on my computer, but you'll have to wait a couple of days so I'll test the code on a Windows 11 computer (maybe it won't work on Win11 ?)

I am away from my PC right now and won’t be able to test until later in the day. However, I can already see where I went wrong when obtaining the control handle. I had the CLASS name in the wrong parameter. This gives me hope now considering your success with it as well. I will  post back in a few hours.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...