Home Library Learn Downloads Support Community
Sign in | United States - English | |
This topic has not yet been rated - Rate this topic

Testing and Debugging Applications by Using Surface Simulator

Surface 1.0 SP1

You can test and debug a Microsoft Surface application from Microsoft Visual C# 2008 Express Edition (or Microsoft Visual Studio 2008) like you would test and debug any other application. However, keep the following Microsoft Surface-specific factors in mind:

  • Start Surface Simulator before you start an application that you want to debug.

  • You must include the appropriate API in your application so that it loads and orients properly from Launcher.

  • You can run and debug a Microsoft Surface application at any time.

ImportantImportant
When you try to use the Microsoft Surface SDK samples on a separate workstation, you must run Surface Simulator before you open a sample application.

ImportantImportant
When you test and debug your application, you do not have to create the XML file to register it. When you open and debug your application from Visual C# 2008 (or Visual Studio 2008) on a Microsoft Surface unit or in Surface Simulator, the Microsoft Surface software automatically registers your application so that it works correctly with Launcher. However, remember the following caveats for automatic application registration:

  • Automatic registration works only in administrator and user debug modes, not in user mode. To enable automatic registration in user mode, set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Surface\v1.0\ModeProfiles\User\Shell\ApplicationConnectionPolicy to 0 (zero).

  • Automatic registration does not work for attract applications because the attribute that specifies an attract application is located in the XML file.

  • Automatic registration works only for the first running instance of an application, based on the application's file name. For example, if you start debugging an instance of your application from Visual C# 2008 (or Visual Studio 2008), and then you open another instance by clicking the executable file in Windows Explorer, the second instance will not load because it cannot register with Surface Shell.

Testing Guidelines

You should test your Microsoft Surface application for the following items on a Microsoft Surface unit instead of on a separate workstation:

  • Tracking content. You can track contacts more easily by using Surface Simulator than by using a Microsoft Surface unit. If your application has elements that can be dragged, test their performance on a Microsoft Surface unit.

  • Simulating jitters. Surface Simulator does not simulate a jitter from a finger input that you can achieve when you rapidly move your finger short distances on a Microsoft Surface screen. To get accurate results for jitters, test your application on a Microsoft Surface unit.

You can use Surface Simulator to test for the following features:

  • Touch input. Touch input differs from mouse input because contact events in your application are actually triggered. Surface Simulator provides input by calling the Vision System and Core API layers. Therefore, you can use touch input to trigger contact events in your application. That is, the application does not know that it is being tested on a workstation instead of on a Microsoft Surface unit.

  • Rapid prototyping. You can record a test gesture (such as simultaneously dragging three pieces of content away from each other), and then you can quickly play that gesture with each prototype iteration.

  • Easier prototyping. Surface Simulator enables you to test the look, feel, and basic usability of your interface on a workstation, instead of on a Microsoft Surface unit.

For more information about testing Microsoft Surface applications, see Testing and Debugging.

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ