Select all text in a parts editor

We have this type of thing on our TODO list, but need to work out exactly how it should work. Currently, the plan is to:

1. Add new routed commands for CopyValue and PasteValue, and map these keys to Ctrl+Shift+C and Ctrl+Shift+V respectively.
2. Add a context menu with the normal Copy/Cut/Paste commands, which would function on the active part, and add Copy/Paste value commands for updating the overall value.

What are your thoughts on this? Did you have something else in mind?

Having two different copy and pastes will definetly confuse the end-users.

A way to highlight all parts would be best. Maybe do it only when a user tabs in.

Also if everything was selected any key strokes would obviously effect the first part while clearing the ones after.

It just has to feel natural. The parts editors are great, but in business apps users are accustomed to certain key and navigation behaviors.

Thanks,

Kavan

Hi Kavan,

Thanks for the input, and we talked it over a bit more and tend to agree. There atleast one gotcha with trying to implement SelectAll, Copy, Cut, Paste, and Delete for the "control" level. Editing in the parts currently works like a TextBox. Therefore, the Ctrl+A would still need to be used to select all the text of the part, in order to overwrite it all.

We've had requests for a feature that would basically remove the caret, and require the user to re-type all the text for each part. So for the year of a DateTimeEditBox you couldn't move over and change the last digit, you would have to re-type the first three also. This would work around that, but what we are discussing here would have to work without that feature enabled also.

What we were thinking was:

1. SelectAll would work like a toggle.
- If currently no selection, SelectAll would select all the text of the active part.
- If all the text of the current part is selected, then SelectAll would be handled by the PartGroup/PartEditBox and select all the text from all the parts.
2. Copy would copy the current selection (whether at Part or PartGroup/PartEditBox level)
3. Cut would copy the current selection (whether at Part or PartGroup/PartEditBox level), but would also delete the selected parts (essientially null out the value).
4. Delete would functional normally if no selection or the selection is contained within a part. Otherwise it would delete the selected parts (essientially null out the value).
5. Paste would first be seen by the Part (really a MaskedTextBox). If the clipboard text can be pasted into the part (without violating any masks), then it would insert the text into the part. If the text cannot be pasted (for whatever reason), the PartGroup/PartEditBox would get a crack at it. The PartGroup/PartEditBox, could then attempt to update several parts based on the specified text.

Some other ideas we had are:

6. Parts probably need a way to identify that they are "selectable". This would help to visually present the selection of multiple parts, if for example there was a button
between the date and time in a DateTimeEditBox.
7. If there is no selection, should Copy do nothing, copy the current part's value, or copy the control value?

How does that sound?

That definetly would make it a more natural experience.

As for #7 I would think there should be a property for this. Sometimes, expecially for complex scenerios you would want copy to function even if there was no selection.

In fact, having some kind of hook as to what to copy would be useful as well. It would allow us to apply formatting and the such.

Thanks,

Kavan

We are currently implementing this feature and wanted to get input on how the cut/copy/paste will work.

Certain types, such as Color and the new TimeSpan, do not have native support for format strings (or parsing those strings). For example, with ColorEditBox you can specify a format of "'Red='r, 'Green='g, 'Blue='b" to intermix the color parts with liternal strings. But, this same format cannot be used with the Color type to produce a string. Nor can the string "Red=255, Green=0, Blue=0" be parsed by the Color type.

Currently for automation, we simply return the Color value as a string using Color.ToString(). So in the example above, the string would be "#FFFF0000". Additionally, when trying to set the value using automation the string value must be parsable by Color.Parse(string).

With cut/copy/paste, we can either leverage the existing code used by the automation peer or we can build something that is able to handle our format strings. If we use the same code as the automation peer, then what gets copied to the clipboard is not the same as what is being displayed (but this string can be used in other non-PartEditBox controls that accept color strings). If we build something to handle our format strings, then what you see is also what is copied to the clipboard (but cannot be used in other controls as it's a non-standard format).

Do you feel that cut/copy/paste should use the standard formats (e.g. reuse the automation peer code) or should be more WYSIWYG?

Hi,

I definetly feel the copy/paste process should be WYSIWYG. The reasoning is the end-user in 80% of use cases will be copy out or pasting in and it would definetly feel more natural to get exactly what was in the editor.

Maybe a better way to explain it is that most users feel they are interacting with a plain old textbox and as such would expect to just get the text displayed.

But, your point about the standard formats is interesting. Would it be possible to expose the whole process through commmands, events or value converters so that in the edge cases we could hook the process and make our own conversion routines?

Thanks for all the hard work!

Kavan

I think there is a nice middle ground here. I would suggest the following:

• Add a special editor state for "Select All", in which the editor shows its entire contents highlighted (as if it were a standard TextBox).
• Implement two commands: "Copy Text" and "Copy Value". Include both in a default context menu (similar to that used by the TextBox).
• "Copy Text" (Ctrl+C) copies the textual value in the editor.
• "Copy Value" (Ctrl+Shift+C) copies the actual Value property.
• Use a single "Paste" command that can either accept a typed value (equivalent to what was copied using "Copy Value") or parse a string literal (equivalent to what was copied using "Copy Text").

The tricky bit is how to handle copying/pasting part values versus the value of the entire editor. I think it's important to consider which is the more valuable, and which is the more common use case. I think that in most cases, being able to copy and paste individual part values is of lesser value, since these values are generally small and can be committed to memory by the user (month, hour, etc). Copying and pasting entire editor values, however, is probably a much more common scenario (I'd estimate 80% vs. 20%), so I think this ought to be the default behavior.

Consider this:

• Add a property to toggle copy/paste support for individual editor parts (off by default).
• If the above property is enabled, copy/paste works on the highlighted part by default. Double-clicking anywhere in the editor, or using the Ctrl+A key gesture, enters "Select All" mode. Copy/paste operations now affect the entire editor.
• If the property is disabled, copy/paste values affect the entire editor by default.
• To make the behavior more obvious to the user, perhaps opening the context menu could temporarily trigger the "Select All" state (until the context menu closes). Perhaps the "Copy" key gestures could have the same effect if the part-based copy/paste support is disabled.

Mike

[Modified at 06/23/2009 09:53 AM]

Some more background for the discussion. Currently, the EditBoxes have a single default PartGroup, which in turn can have 1 or more Parts (or TextBlocks for literal strings). The default Parts each utilize a MaskedTextBox internally, which handles the clipboard operations in the current version.

We've been working on updating the SelectAll command to toggle between selecting all the text in the active MaskedTextBox and selecting the associated PartGroup. When the PartGroup is selected, it appears that all the parts and literal strings are selected and clipboard operations would be ignored by the MaskedTextBox (and thus handled by the PartGroup at the value level).

Kavan - We could add a way to "hook" into the clipboard processing, but this would probably only apply to the PartGroup. The MaskedTextBox is just dealing with text, so there is no formatting problem there.

Mike - The SelectAll changes are essientally your first bullet item. As for the "Copy Value", I'm assuming that means to copy it as text using the standard format. Is that correct? This is similar to the idea discussed above, but combined with the SelectAll changes this might be reasonable (Kavan?). Really, the Copy command would always copy the text as-is, while the CopyValue would copy the Value using standard formats.

An alternative would be to have a single Copy command, which copies either the text as-is or using a standard format based on a configurable property. This prevents you from using both modes together though.

In my post above, "Copy Text" would copy the editor value as text (basically WYSIWYG--the exact text displayed in the editor). "Copy Value" would copy the underlying value of the editor (a DateTime, Color, Double, Int32, etc.).

It just dawned on me that the clipboard supports multiple data formats, so really you wouldn't need two Copy commands--you could just set two different clipboard values (one for the text representation, one for the typed value).

Mike - Yeah, we had just talked about that internally.

Here is a list of how things would work:

Special mode for part group select all

When in part group select all mode, typing letters, etc. will delete current value, focus first part and pass typed characters there

Ctrl+A when no selection in part, selects single part content if selection is supported; next Ctrl+A enters part group select all mode; future Ctrl+A toggles between part select all and part group select all

Ctrl+A when some but not all selection part works the same as no selection in part

Ctrl+A when part text completely selected, enters part group select all mode; future Ctrl+A toggles between part select all and part group select all

When in part group select all mode, Ctrl+C does part group clipboard copy

When in part group select all mode, Ctrl+X does part group clipboard cut

When in part group select all mode, Del clears the entire part group value

When in part group select all mode, actual value (Int32, etc.) is always cut/copied along with text to clipboard

Ctrl+C when no selection should behave as if in part group select all mode and Ctrl+C pressed

There would be an option to copy displayed text vs. parsable value text

Text pasted into the part group can be in the current configured format, or a standard format; A configurable converter would be called if the pasted text could not be parsed.

An actual value pasted into the part group would assign the value.

This design also considers support for a free-text mode (such as entering yesterday in the DateTimeEditBox), which will be added in the future.

Thoughts?

I'm a bit confused about the concept of "part select-all mode". Is this the same state as in the current editors when an entire part is highlighted (e.g. after tabbing to another part)? If so, then the above scheme sounds great to me.

Mike

Yes that is correct, same as when tabbing into a part.

Has a "select all" been implemented for this control?

Hello,

Yes, this was added to WPF Studio 2009.1 build 0501.

Why is the contextmenu not showing? Am I missing a property that needs to be set?

Hi Maria,

There isn't a default context menu in the current version. We have a TODO item marked down to see about adding this in the future.

It would be nice to have this, since contextmenu is almost part of every editor control.
It just gives the end-user some flow consistency.