This is going to be a long rambling blog post. You have been warned!
It all started with this thread. The moment I saw the thread I immediately tried it out on my VDF 16.1 app. To my surprise, double-clicking on any textbox would copy the content of the textbox to the clipboard. I also had my coworkers to try it out to make sure it wasn't a Windows 11 thing. Some of my coworkers are running Windows 10 and the double-click-to-copy feature still works for them.
Next, I tried double-clicking all the STATIC controls in my C++ programs. None of them has the double-click-to-copy feature. That seems to imply it is a VDF feature instead of a Windows feature. I decided to investigate a bit more.
I wrote a small VDF UI program in Notepad but that program wasn't exhibiting the behavior. However the moment I added a manifest file to that VDF UI program, the behavior showed up. That didn't seem to make sense because it was hard to imagine (but not impossible) VDF would program different behaviors for text box depending on the version of Common Control. (As a reminder, manifest file is mainly used for controlling the version of Common Control that is used by the program). Then I imported a STATIC control using cWinControl in VDF. The newly imported control is not exhibiting the behavior, with or without the manifest. Again, that seemed to indicate it's a VDF feature.
I decided to install VDF 7 on my machine to verify my finding. Unfortunately the moment I put a manifest file to the DFRun.exe, VDF 7 decided to stop working by showing me a series of erorr message boxes. I didn't feel like figuring out why VDF 7 would stop working on Windows 11 after a manifest file was created for DFRun.exe. So that's a dead-end.
By the time I saw the thread on the forum, I already saw Wil van Antwerpen had already tried augmenting Mouse_Down/ Mouse_Click with no avail. I decided to go with my ultimate hack - API hooking. In order for any program to copy things to the clipboard, the Windows API call OpenClipboard has to be called at some point. I was able to use Process Explore to find out what VDF DLLs were loaded in my simple UI program. The only DLLs that jumped out at me were VDFVM16.DLL and DFCTRLS16.DLL. I wrote another DLL to hook into the API call OpenClipboard in both VDFVM16.DLL and DFCTRLS16.DLL. However somehow OpenClipboard was not getting called. That seemed to point the finger back to Microsoft.
Not giving up yet, I used Spy++ to see if there was some kind of special message being sent to the TextBox when you double-click it. I was expecting messages like WM_COPY, however I saw WM_DESTROYCLIPBOARD instead. Hmm, WM_DESTROYCLIPBOARD is only sent when EmptyClipboard is called. I set out to hook into EmptyClipboard, but it's not getting called. Nothing made sense. I decided to call it a night.
The next day, Vincent Oorsprong added a post to the thread, saying that it's a Windows feature and the same thing would happen to all the .NET programs (He pointed at a Stackoverflow post). Like I said, the behavior was not showing up in all my C++ programs. It just couldn't be a Windows feature (or could it?) VDF definitely does not use .NET controls. I replied to Vincent's post about my findings. Interesting enough, Mike Peat pointed out that in the Open File Dialog inside Notepad, the double-click-to-copy feature exists, and I was able to verify that the control in question was indeed a native Win32 STATIC control.
Since Vincent's post, I decided to Google about the issue. I didn't Google anything up to this point because I was pretty sure it was a custom VDF feature. Alas I was wrong. Besides .NET, some AutoHotkey users were experiencing the same behavior. They were putting the blame on SS_NOTIFY. Then it dawned on me.
Most people would not create STATIC control with SS_NOIFY because most people don't care to be notified if the user double-clicks on a TextBox or STATIC control. Without SS_NOTIFY, you won't get the WM_LBUTTONDBLCLK (or Mouse_Click in VDF) notification. However VDF does care about those events because VDF wants to be able to generate the Mouse_Click event for TextBox in case you need it. The copying is done within the DefWindowProc of the STATIC control and there is not much you can do to change the behavior by augmenting Mouse_Click/Mouse_Down (Not even with Windows_Override_State). I guess both .NET and AutoHotkey always create their STATIC control with SS_NOTIFY.
A simple solution would be to take out SS_NOTIFY by doing Set Window_Style SS_NOTIFY to FALSE in VDF. However that didn't stop the behavior. I then launched Spy++ to find out exactly what window styles a TextBox has. To my surprise, there was no SS_NOTIFY. But then, I saw TextBox had the class style of CS_DBLCLKS. Therefore on Page_Object of a TextBox, I took out the CS_DBLCLKS by using SetClassLong. Viola. However, by doing so, every TextBox will lose the Mouse_Click event. I decided to go back to my API hooking method.
Since I mentioned that this behavior only happens when you have a manifest file, that implies that the copying is done inside COMCTL32.DLL. I set out to hook into OpenClipboard within COMCTL32.DLL, and then another viola. In my code, if I see OpenClipboard is called by DFTextBox (The actual Windows class name for TextBox in VDF), I would simply return FALSE. All was well.