Windows Phone 7 copy/paste demo … with multiple paste

Sure, there are plenty of Windows Phone 7 copy/paste videos online, but Leon Zandman has created one showing off some truly unique functionality: The ability to perform multiple paste operations. That is, once some text is in the clipboard, you can continue pasting it multiple times even though the Paste button has disappeared from above the keyboard. Check out the video for the how-to:

This entry was posted in Windows Phone. Bookmark the permalink.

20 Responses to Windows Phone 7 copy/paste demo … with multiple paste

  1. It’s hardly unique. iOS has always been able to do this since copy & paste was implemented. And the paste button continues to appear where appropriate.

    • Just to add to the above. I’ve watch the video a couple of times, a whilst it’s great to see copy & paste coming to WP7, I was expecting a bit more than what we’ve seen.

      Let’s hope we see more features added in the future.

    • wsdavis508 says:

      Seriously. I’m becoming more and more disenchanted with my WP7 phone. I was excited when it first came out; lots of hope for future potential. But after 4 months, functioning copy/paste is all we have to be excited about? MS needs to iterate faster and start pumping out missing functionality.

      • jkavanagh58 says:

        I have to agree. Sure Copy & Paste will be a nice addition but for this to be the main item in the first update is very disappointing. I am still enjoying my WP7 device compared to my Droid but it seems the platform has already lost steam. I hope that is not true.

    • ziggyfrommars says:

      You’re missing the point. It’s got nothing to do with this being a unique feature.
      Since the developer update rolled out there have been multiple videos on Youtube stating that you can only paste things once from the clipboard. This video is just showing that that’s not true.

  2. blkballoon925 says:

    After the speculation last year that Windows Phone 7 would have a toast-style copy/paste bin that you could drag and drop “items” like text and graphics into and out of, I was quite disappointed when this was first announced. I thought the paste implementation looked really “hacked” together, with the paste icon popping up in the keyboard suggestion tray. But I have to admit, after watching this video it looks pretty good, and much more professional than I originally remember. I’m impressed. I’d be more impressed if the camera settings memory was fixed in the update, but that’s another disappointment for another day.

    My only question is: how do you paste into apps where their text fields don’t show the word suggestions bar above the keyboard?

    • lzandman says:

      Once you’ve copied some text to the clipboard, every keyboard type (for devs: every InputScope) will display that gray word suggestion bar. Even if it doesn’t actually show the word suggestions. So you are always able to access the Paste icon and use it to paste text.

      On phones with physical keyboards the gray bar will be displayed at the bottom of the screen.

    • lsobrado says:

      such an app would require the developer to go out of their way to not to use the stock text box. The copy/paste function is associated not only with the textbox but with the on screen keyboard object. Now let’s think about this for a minute. Why would any developer want to make their own text box? Typically it is because they need features they lack and extending the existing textbox via class inheritance simply does not work well. Clearly for 99.99% of the developers, the stock textbox is fine. For the remaining few, they will still have to provide a method of input which means, you guessed, they will either have to make their own keyboard, or use the stock one, which will give them paste at the very least and leave copy to their own implementation.

      I didn’t yet install this new set of tools but in all the other MS platforms, there is programatic APIs to get data from the clipboard. Therefore it is the logical conclusion that developers will extend copy/paste beyond textboxes as long as microsoft gives them programatic access to the clipboard.

      In conclusion, I think this is a non issue.

      • tw says:

        It would be logical but unfortunately unlike in all other MS platforms there is no new programatic API for the clipboard in the first WP7 update. I don’t know if there will be one in some future update.

        But right now, as a 3rd party app developer you cannot extend copy and paste beyond the textbox control. You cannot even put text into the clipboard. So no own implementation of copy for you…

        All you can do is using textboxes everywhere you want the user to be able to copy text even if it is read only text like in lists, buttons captions etc..

  3. misterbeak says:

    I watched this. Copy/paste on any mobile device requires some commitment to learn the process from the user. I wish all OSs’ would follow the same process like they do on the PC/MAC/UNIX workstation.

    • kabukin0 says:

      I doubt UNIX-people are the target audience for entertainment-phone-xbox users.

      I also doubt that UNIX UI approach should be trasferred to a phone with no keyboard mouse or anything.

      What are you talking about ? You want to press Ctrl+C to copy ?

      • tw says:

        Well Ctrl+C / Ctrl+V worked in Windows CE / Windows Mobile for 10+ years on real and virtual keyboards. It just worked and not only in textboxes.

        And iOS (iPhone) and Android are both based on (different variants of) UNIX.

    • jkavanagh58 says:

      Great point misterbeak. I had Copy & Paste on my Droid and quite frankly it was more frustrating than helpful.

  4. kabukin0 says:

    I want to make a comment that isn’t related to this post, but rather the update, and it has to do with … multitasking /app switching.

    I assume that memory management is still improving in WP7. Although people say that WP7 doesnt have appswitching/multitasking ability, it is already in the OS. When beeing in an application, let’s say seesmic twitter client, clicking a link and opening internet explorer, -if you then use the back button, you “resume” the seesmic client to where you were before. This goes for other apps to, the back button does resume applications in their previous state.

    I bet it will not be long before we can press and hold the back button, to see applications that have been put in frozen mode, that we can resume. This probably takes more memory management to achieve, but I’m happy that it seems the OS already has the capability to freeze apps and resume them…

    • tw says:

      WP7 does not “freeze” (3rd party) apps and resumes them. They are always terminated. If you leave the app by using the back button it has to close anyway according to MS rules. But if you leave it by pressing for example the Windows button the current running app gets a so called “tombstone” in the system. But a tombstone it not an memory image or something. Just kind of a hint. The app is terminated and removed from memory (RAM). The app just has the option to save its current state because it gets a signal (an “event”) from the system before final termination. If the user later uses the back button the system looks at the staple of tombstones and restarts the one on top. The apps gets another special “activation” event so the app knows that it is a restart and is should reload the app state it had saved before.

      So it just looks like the system is “freezing” the apps but in reality the apps have to handle all the house keeping themselves. Not all developers care thus you can find apps which do not “freeze” but always start on the first page if you leave them. It’s obvious that this is also much slower than keeping multiple apps in RAM and switching between them.

      • lzandman says:

        @tw: You’re not entirely right. In some cases Windows Phone apps do get ‘frozen’ (i.e. their pages and state are kept in memory, without the app developer having to do anything special). I quote from the official Windows Phone Training Kit:

        “An application will not be automatically tombstoned when it launches an experience that feels, to the user, like an extension of the original application. These experiences are native flows that help the user complete some task like choosing a photo. The reason behind not tombstoning in these cases is to ensure a smooth flow between the application and the experience it has called [i.e. no delay between choosing a photo and returning back to the application which uses it].”

        It is said the coming first phone update decreases the startup time for some apps, so they should have a better tombstoning experience.

      • tw says:

        I was refering to switching between separate apps. Your quote from the training kit doesn’t refer to normal app switching but to the “Launchers” and “Choosers” API of WP7. Which is a different thing.

        These are APIs which allow 3rd party apps to invoke limited common tasks which otherwise they would not be allowed to invoke from their isolated sandboxes. For example for making phone calls, browsing the web, or selecting a phone number from the contacts list.

        In the paragraph following your quote from the training kit they list 7 tasks which are supposed not to trigger an automatic tombstoning in the calling app. But 6 out of these 7 are just simple “Chooser” tasks. For example to select a phone number and return it to the calling app. You can think of these tasks as kind of popup input windows (modal dialogs).

        Only one, the “MediaPlayerLauncher” task, is a “Launcher” task which is indeed launching another app namely the built-in media player. But media player is special because it is not a “normal” app because it is allowed to play music in the background. Tombstoning the calling app would make no sense in that case. All other Launcher tasks tombstone the calling app. Also you cannot launch another 3rd party app from them anyway. You can only launch the built-in tasks provided by MS.

        What I wanted to point out is that tombstoning (“freezing”) is not transparent to apps since normal apps are not kept in memory. So while a task switcher like kabukin0 suggests would be possible by making the “tombstone stack” visible to the user in some way so he could select from it. But because of all the permanent state saving, app reloading and state reloading going on it can never be as a fast as a real task switching system which keeps the process images in memory (regardless whether it multitasks or not). BTW I think it is also the reason that WP7 is more in need of fast flash memory access than other systems.

  5. ejlee2006 says:

    There’s nothing exciting about this!!!!! I need to send my videos,, that’s all I need, I dont really care about copy n paste,.

  6. Pingback: Zune Software Update Out Now – Windows Phone Update Out Soon? Sigh… NO

  7. Pingback: Numerous new Windows Phone 7 features coming out this year. First update to hit mid March. - MSDN Blogs

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s