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 firstname.lastname@example.org, 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 email@example.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