Copy/Paste Limitations in Windows Phone 7 Update

A few weeks ago, the day after Steve Ballmer's keynote address at CES, Microsoft posted some information about their upcoming update for Windows Phone 7 that contained the following text (emphasis mine):

"Soon you’ll be able to copy text from emails, text messages, web pages, and Office Mobile documents, and paste it anywhere you can type."

Bummed, I tweeted that I was disappointed that the 'copy' portion of 'copy & paste' wouldn't work in third party controls (and later clarified that I was specifically referring to copying normal (non-editable) text such as that found in a Twitter stream, Facebook statuses, and most other apps - I assumed you would be able to copy from editable text inputs no matter what). I got a few replies telling my I was misinformed and that the WP7 UI team wouldn't add copy/paste some places but not others, even though a few other folks had the same concern. The question made it all the way to Microsoft's Charlie Kindel who said "of course C&P will work in Silverlight WP7 apps.". When pressed further, he added "It's really simple: There is no copy & paste API in WP7 update. Edit controls just get end user behavior automatically".

His specific use of 'Edit controls' along with the wording of the original update information page seemed to confirm that copying would be limited in third-party apps, but the blogosphere seemed to take it to mean that us doubters were wrong and there was nothing to worry about.

Fast-forward a few weeks and Chris Walsh and friends (of the ChevronWP7 unlocking tool) meet with MS to discuss the homebrew community and other issues surrounding WP7. As part of that, the devs received some developer phones that already had the upcoming update applied. In Chris' post, he provides a quick overview of the WP7 update and specifically calls out the copy/paste functionality. Sure enough, the 'pasting' part works as expected, and you can only copy from first-party apps and TextBoxes in third-party apps - just as I had suspected. Thus you still cannot copy a tweet from the Twitter app or a status update from Facebook, even though users will be expecting the ability to 'copy and paste', not 'copy from some places and paste'. MS went out of their way to add copy ability to native apps like email and the browser, but neglected to provide the ability for third-party apps to do the same. In fact, it is rumored that the copy function in the SMS (Messaging) app operates differently, presumably since the 'copy' functionality is not standardized at the OS level.

So, now that our suspicions are confirmed, Chris Walsh suggests that WP7 devs simply put all of their text into TextBox controls to solve the issue. I sincerely hope that devs DO NOT do this though. Beyond being fundamentally wrong (TextBoxes are for input, TextBlocks are for display), TextBoxes trigger the software keyboard and thus it will be popping up all over the place, even when the text is intentionally not supposed to be editable. As a end user, that user experience would drive me crazy.

So what would I do? I would hope that Microsoft bakes the 'copy' functionality into text display-only controls like TextBlock as well. If they don't want to automatically make all text selectable/copyable, perhaps a property on TextBlock that a dev can set to mark the text as copyable (or not)? That would remove the constant popping up of the software keyboard while still providing the behavior that user's would expect. Seeing as how there is not even an update for when this first update will roll out, I am not holding my breath for a second update to fix the copy & paste shortcomings to be released any time soon.

UPDATE: Chris Walsh responded to my concerns and posted a sample of using the IsReadOnly property on a TextBox to prevent the software keyboard from popping up. That was something I didn't think of and does indeed solve that issue. However, it doesn't help with having formatted text or having clickable links within a TextBox (think of a tweet with a link in it: the link is usually a different color and clickable while the plain text is not). Both of those are much harder to achieve when using a TextBox control. Chris said in a tweet that "devs shouldn't have to worry about it" and I agree completely - I just feel that recoding your app to shoehorn some functionality into a control that was designed for something else or having end users complain to you that copy & paste doesn't work for your app *is* something devs have to worry about. I respect Chris' opinion on the matter - I just have a different opinion.