WPF “TextBox” controls do not correctly group regular text and special characters as one unit when double clicking to highlight text - by Jason Webb

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 367347 Comments
Status Closed Workarounds
Type Bug Repros 5
Opened 9/11/2008 9:42:29 PM
Access Restriction Public


I work with a group of young developers using WPF and love it. However, one thing that frustrates both ourselves and our users is the “TextBox” control and the edible “ComboBox” control both don’t handle special characters (such as the @ symbol, or a period, or a backslash) alongside regular text the same and familiar way that both MFC and Windows Forms text box controls do when selecting a certain area and double clicking on it, and I think it’s crucial that this gets fixed so WPF text boxes can gain the full functionally that the MFC and Windows Forms “TextBox” and “ComboBox” controls have.

In MFC and Windows Forms “TextBox” and “ComboBox” controls, when one or more special characters (such as a period, a colon, or the @ symbol, etc) are associated with words as being part of a single phrase, when a user double clicks on text with one or multiple special characters next to the text, the whole combination of text and special characters will all be selected, just the same way a single word would be selected. For example, an E-mail address is always considered one phrase, so if you double click on anywhere on an E-mail address typed in a “TextBox” of “ComboBox”, such as jasonw15@msn.com, which has an @ symbol and a period, the entire E-mail address will be selected in MFC and Windows Forms apps. For another example, a webpage address is considered one phrase, so if you double click on any part of a webpage address in a MFC or Windows Forms “Text Box” or “Combo Box”, such as http://www.microsoft.com (which has 2 forward slashes, a colon, and two periods), the entire address will be selected.

However, the WPF “TextBox” control and edible “ComboBox” control both don’t group special characters together along with regular text when double clicking on a certain area to select a an item, and instead they treat text and special characters as separate entities, even when they’re right next to each with no spaces, and this is not how and “TextBoxes” and “ComboBoxes” are designed to work in Windows, ever since the first “Text Boxes” in Win95.

For example, if I have jasonw15@msn.com typed in a WPF “TextBox” or “ComboBox”, and I double click on the jasonw15 part of the address expecting to have the whole E-mail address selected like all Windows apps are supposed to, it will instead only select the jasonw15 part of the E-mail address, and the @msn.com will remain unselected. If you clicked on the jasonw15 part of an E-mail address in an MFC or Windows Forms app, as mentioned above, the entire E-mail will be highlighted, as these apps see this as one phrase, like they should. This flaw in WPF “TextBoxes”/”ComboBoxes” can be replicated with any variety of text and special characters right next to each other…. For another example, if you have http://www.msn.com in a WPF “TextBox” or “ComboBox” and you double click on the word “msn” expecting the whole address to selected, only the word “msn” would be selected, and 
http://www. and .com would not be highlighted, unlike how MFC and Windows Forms apps would select the entire address, so this seems to be a big flaw to fix in WPF controls so they can act like all of their other counterparts in Windows Forms and MFC apps. 

With .NET 3.5 SP1 out now, I know all of you at Microsoft are busy working on creating new WPF controls and modifying existing ones.  I think it’s crucial that both the WPF “TextBox” and “ComboBox” controls (as well as other text input controls) get fixed and “updated” to group regular text and special characters together as one unit/selection when a user double clicks to make a to make a selection, just like the “TextBox”/”ComboBox” controls in Windows Forms and MFC programs do. When double clicking on something such as an E-mail address or a webpage address, users expect the entire E-mail address, webpage address, or any variation of text and special characters next to each other with no spaces to be completely selected, just as all text boxes have done since the original Win32 controls in Windows 95, and WPF “TextBoxes”/ComboBoxes” need to be fixed to also operate this same way. While working with developers and clients, many people find this problem to be very irritating and frustrating as they are used to just double clicking, and this issue is something that shouldn’t be too hard to update, but it would also provide a HUGE benefit by fixing a loose end in one of the “Key” areas of the WPF control library.

I attached an image that demonstrates this named special-characters.jpg. Please maximize it to full size so you can clearly see it. Users can find it at http://jasonw15.741.com/special-characters.jpg

I also attached a demonstration video named “special-characters.wmv”.  Please watch this video in its entirety and DO NOT seek with the seek bar, as the “WMV9 Screen” codec has a problem seeking, and it will often cause the video to hang for some time.  Users can view the video at http://jasonw15.741.com/special-characters.wmv
Sign in to post a comment.
Posted by Jason Webb on 11/21/2008 at 4:17 PM
Thanks for the update… I really appreciate it. Since it is the intended behavior, I probably should not have submitted it as a “Bug”. Anyway, with that in mind, since VS 2010 is now in beta, please focus your attention to my follow up report (ID 375044) at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=375044, which is a “Suggestion” report this time, and it’s targeted as an update in the future release of VS 2010.

Thanks again, and keep up the great work!
Posted by Microsoft on 11/20/2008 at 11:28 AM
As discussed in the forums, the current selection behavior in WPF is by design. We'll consider adding the alternate behavior in future releases. Thanks for your detailed feedback!

WPF Team
Posted by Jason Webb on 10/12/2008 at 12:54 AM
Thank you very much for taking the time to acknowledge and Escalate this issue. However, based on the comments here, as well as further feedback from my fellow developers, it seems more and more like users want the abilities that the “RichTextBox” currently has, which allows users to double click to select strict groups of text like “TextBoxes”/”ComboBoxes” currently do now, but it also allows users to “Triple Click” to select an entire phrase/group of text. With that in mind, I’ve gone further to make a follow up suggestion feedback report at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=375044 which suggests you add the some of the CORE abilities from the “RichTextBox” to the “TextBox” and ”ComboBox” controls as standard features in the next release of WPF (MUCH more info on the actual new suggestion page). If you could also “Escalate” this new suggestion feedback report (ID 375044) along with this feedback report here on this page, and group them together to go side by side each other for your evaluation, I’d really appreciate it. Hopefully together, we can make WPF and the next release of Windows the best it can possibly be!

However, keeping to the confines of this bug report page itself, to see an a example program I made that demonstrates what the “TextBox” control would act and look like if it had key features from the “RichTextBox” control built into the “TextBox” control as standard abilities, such as the ability to “Triple Click” to select an entire text field. You can download it at http://jasonw15.741.com/WPF-Example.zip . The program is inside. Thanks again, and keep up the great work!
Posted by Microsoft on 10/8/2008 at 6:50 PM
Thanks for your feedback. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Posted by n4cer on 10/5/2008 at 12:25 AM
While I believe the current selection behavior for plain text-based controls in WPF should change, I think the controls should depart from the behavior of their MFC/Win32 counterparts and actually adopt the selection behavior of the WPF rich text controls (i.e., double-click selects a word part and triple-click selects the entire word). I like this behavior most, and it would make the selection behavior in WPF more consistant overall.
Posted by DutchMarcel on 9/30/2008 at 1:16 AM
Already posted it in the WPF forum thread, but I think it's worth repeating it here:

When I double-click on an email address it usually is because I want to copy the whole address to my new email or contact info or as data from one application to another (or even from "email" to "confirm email" field, I hate those fields ;-) ).
But... email addresses and hyperlinks are about the only useful examples for this. I would certainly not like it when I double-click the last word of a sentence and the dot gets included!

Personally, I like Firefox's url input-box solution. First focus selects all... fine. Double-click a word selects that word... also fine. Triple-click selects the whole url... very nice!

I think it would be nice if a triple-click would recognize a whole phrase like an email address or a url. This would conflict a bit with Word though, because in Word this feature selects a whole paragraph...

So, I don't consider the current situation as a bug, so I'm not going to vote for this, but I do think there is room for improvement :-)

Posted by Tim Dawson on 9/29/2008 at 12:34 AM
WPF textboxes are NOT Win32 textboxes. They are newer, better, and contain culture-aware code of what constitutes a word. This is not a bug, and thank god WPF is a departure from primitive Win32 code in many respects including the awful "word selection" that Win32 textboxes had. WPF textboxes are even approaching Microsoft Word text services in terms of richness, and that is better for everybody.
Posted by EvilPenguin on 9/28/2008 at 7:04 PM
I personally don't think this is an issue -WPF is not Windows Forms or MFC. It may be reasonable to ask for a way to configure this functionality, but it is clearly intended behavior, and useful in a lot of circumstances.

It seems presumtuous to call it a bug/problem and ask for the default behaviour to be changed to suit your preferences.
Posted by Jason Webb on 9/27/2008 at 5:36 PM
For users who want to test this right away and don’t want to open up Visual Studio to make your own apps in order to reproduce this bug, I made an example WPF C# program with a “TextBox” control and a “ComboBox” control that you can reproduce the bug in, and I made an example Windows Forms C# program that also has a “TextBox” control and a “ComboBox” control that you can see behaves exactly like all other Windows programs and selects the entire phrase of text when you double click on it, unlike the WPF example app. You can find the WPF example app at http://jasonw15.741.com/WPF-Example.zip and the Windows Forms example app at http://jasonw15.741.com/WinForms-Example.zip
Posted by Jason Webb on 9/27/2008 at 5:27 PM
Gary4235 in the Validation section made a GREAT point about how the current way WPF text input controls work when you double click on them is very useful in programming tools, and I absolutely agree, because there’s so many different letters and characters all around when programming or scripting code, it’s nice to have it be very “picky” when you double click on items while editing the code. However, like he said, it shouldn’t enabled be default, because regular Windows text controls aren’t supposed to act like this, and it would be great if you took his idea and turned the current, strict selection method OFF by default when using WPF text controls, but also allowed users an option to turn this more picky/strict selection method back on in the “Properties” section of the control, when a user is developing an app made for programming code that would “benefit” from this selection method.
Posted by PattyBergh317 on 9/20/2008 at 12:08 AM
I think this is “extremely” important to fix as normal Windows text box controls aren’t supposed to act like this (see my validation with a few more examples). Along with MFC/Win Forms programs, Java programs with the latest Java Framework do not exhibit this problem, nor do Linux and Mac OS X C++ programs have this issue in text boxes. With both the next release of Visual Studio/.NET Framework and Windows 7 on the horizon, I think it’s crucial to get this fixed so WPF and future Windows 7 apps/controls are not affected by this issue.