Weird "bug" with CStatic controls

[Dan203]

OK I just discovered something weird. If you set the "notify" property of a static control to true then any time you double click on that control it copies the text of the control to the clipboard. I've traced this down to something inside MFC because I can create a very simple dialog based app, with all the defaults, set the static control in the middle with "TODO: Place dialog controls here." to notify and if I run it and double click the static that text is copied to the clipboard every time.

This is using VS2010

Does anyone know of anyway to turn that off? We have a static control in our app that when double click launches a dialog that allows you to change a value. By copying the value of the static it overwrites whatever the user already has on their clipboard, which is usually what they intend to paste into the dialog. So it's very annoying. Plus I was always told it's bad practice to overwrite the clipboard without the user specifically requesting it.

Dan

[VictorN]

This problem is described here. it is delphi, however the problem is the same.

[Igor Vartanov]

Attached you can find the minimalistic Win32 API and MFC apps. Neither of those produces the effect you described. The OS is Windows 7 x64 SP1.

PS. Just made sure, neither is does in Vista x32 SP1.

[Dan203]

After some research I narrowed it down to the manifest. If you don't include a manifest it doesn't do it, but if you do then it does. However without the manifest the controls all look like crap, so that's not a viable option for our product.

[Dan203]

Also subclassing the control and handling the double click myself does not work because the copy happens before the double click handler is called. I verified by adding a break point to the top of the double click handler and checking the clipboard as soon as it breaks.

This is a stupid "feature" they decided to add. Why would they just assume everyone wants to copy the contents of a static control on double click?

[VictorN]

This is a stupid "feature" they decided to add. Why would they just assume everyone wants to copy the contents of a static control on double click?

I agree it looks like "stupid".
I wonder, however, why you are using static control with double-clicking on it. Why not use a button? A read-only edit control?

[Igor Vartanov]

I would disagree about stupid thing.

Being not able to copy a label text is same stupid, or even worse stupid. You might object that it's not that frequent situation when people need a label copy, but the same infrequent label double-clicking is. I assure you, for all those years I deal with Windows, until today, I never had a thought about double-clicking static. Just because I know its a static. Why would anybody double-click static at all?

At the same time I was in need of copying label text too many times, and each time I thought "why wouldn't they make it a read-only edit box?"

[OReubens]

This is an awesome feature, and the biggest fail with it is that they totally forgot to do anything significant with it in the most obvious of places when Windows Vista came around.

For example: It would have been awesome if messageboxes had the message text static control have SS_NOTIFY, but alas...

[Igor Vartanov]

It would have been awesome if messageboxes had the message text static control have SS_NOTIFY, but alas...

Well, classical message box supports Ctrl-C. You should give it a try.

[VladimirF]

Also subclassing the control and handling the double click myself does not work because the copy happens before the double click handler is called. I verified by adding a break point to the top of the double click handler and checking the clipboard as soon as it breaks.

Interesting. The subclassing and handling WM_LBUTTONDBLCLK message (without calling base class' CStatic::OnLButtonDblClk(nFlags, point) works fine for me.
The copy obviously happens in CStatic control's handler for double-click.
Are you sure you have correctly subclass it?
Can you show your code?

[Dan203]

Interesting. The subclassing and handling WM_LBUTTONDBLCLK message (without calling base class' CStatic::OnLButtonDblClk(nFlags, point) works fine for me.
The copy obviously happens in CStatic control's handler for double-click.
Are you sure you have correctly subclass it?
Can you show your code?

You're right I was using STN_DBLCLICK in the subclass, which is called after the copy. If I use WM_LBUTTONDBLCLK instead then I can catch it before the copy happens.

Still think this is stupid. If people wanted to copy the contents of a static they could sub class it and handle the double click themselves. Not sure why they make it the default.

[VladimirF]

You're right I was using STN_DBLCLICK in the subclass, which is called after the copy. If I use WM_LBUTTONDBLCLK instead then I can catch it before the copy happens.

Glad it worked.

Still think this is stupid. If people wanted to copy the contents of a static they could sub class it and handle the double click themselves. Not sure why they make it the default.

Well, some might think that trying to double-click static control to get some action out of it is also not very intuitive.
However, did you know that a simple message box like that:

::MessageBox(m_hWnd, L"This is a test", L"Caption", MB_OK);

supports a Copy command? Hitting Ctrl+C copies this to the clipboard:

---------------------------
Caption
---------------------------
This is a test
---------------------------
OK
---------------------------

<Oops... I see that Igor already mentioned that>

[Dan203]

We have a video editing app called VideoReDo. The static control in question is the one displaying the current timecode. Double clicking on it brings up a dialog that allows you to jump to any time code in the file. The same action can be triggered via a menu item and a key combination, but it makes sense to double click as well. Apparently this "bug" has been there for a while, we just had one of our customers bring it to our attention for the first time.

[Igor Vartanov]

The whole situation just confirms once again the rule of my own: don't mess with classical "old" controls, like static, edit box, list box or combo. Just don't. You want something fancy, you create your own one.

[Dan203]

The control was already subclassed, as we offer skinning and everything is custom drawn, but I use the MFC base classes because it makes it easier to lay everything out in the dialog editor and allows us to use DDX to set the values.