| Comments

I’ve seen some reports and received some emails on email groups that I’m a part of around Windows 8 and Google Chrome browser and how touch is not working.  In fact I was initially confused about this myself because it was working fine for me on my machine (Lenovo x230t) but other people were insistent that it wasn’t working.  Then I asked what machine they were on.

Almost exclusively everyone was on a “high DPI” machine (or had high DPI settings in their display).  If you have a Surface Pro, for example, you are using a high DPI machine.  I installed Chrome on my Surface Pro and indeed saw the problem there.  After some digging it appears to be that Google Chrome is not yet a high DPI-aware desktop application (at least of this writing which was using version 30.0.1599.66 m – phew that was a mouthful of a version number).

Look at this screenshot.  This is from my Surface Pro with no changes.  I’m tapping on the 2nd image in the news highlights (indicated by the touch square indicator) but notice where the target is actually clicking – on the date “October 4” where the context menu is located:

Chrome missed touch target

I asked around the office and received one workaround, which I received, but also found a better one.  Here are both of them for you to consider.

Workaround 1: run in compatibility mode

This involves you getting to the properties of the chrome.exe program and viewing the compatibility tab.  In there you can check the option to disable DPI scaling:

Chrome compatibility setting

I didn’t like this option because immediately after restarting Chrome the display was crisp but “tiny” to see for my aging eyes.  You can see here is the msn.com site before/after this compatibility setting:

Chrome msn.com before

msn.com on Google Chrome with no compat setting

Chrome msn.com compat set

msn.com on Google Chrome with the compat setting enabled

After this setting the hit-targets are fine and work but the content is small (although admittedly more of it is viewable, but that is too small for me).  To mitigate this you can use Chrome’s zoom feature to zoom to 150% to match most closely the high DPI scaling that automatically happens.

Chrome zoom settings

But there has to be a better way…and is (in my opinion).

Workaround 2: set the Chrome flag for HighDPI Support

I learned that Chrome has “flags” that you can set to experiment with certain settings or override other default/automatic settings.  From the address bar, type “chrome://flags” and you’ll see a page of options.  Scroll near the end and you’ll see a “HighDPI Support Windows” setting which is set to Automatic. 

Chrome HighDPI Flag setting

Force this to Enable and re-launch Chrome.  Boom you are working again.  Simpler fix and gets you scaling on your device as well.  Now some of Chrome’s chrome (menus, etc.) aren’t as crisp still but the main content area doesn’t confuse hit-targeting of your touch interaction because of the scale.

The good part is that it appears that the Chrome team is aware of this and a Chrome bug is logged (Chromium Bug 271222: When using the global Windows UI scaling feature, touchscreen touches are off by the set scale).

I don’t use Chrome on a regular basis (nothing against it, just don’t need it) but do get sad when friends have problems so I like to try to help out.  Hopefully if you are in this case with your touchscreen and Google Chrome this will get you fixed up.

Hope this helps!

| Comments

So you got that shiny new Surface device today?  I’m sure you spent the first few hours just opening it up, setting your personal experiences to your desire, re-installing and discovering new apps.

But you are a developer and now you want to see how your app looks on this great device…Here are some tips to get you quickly started.

Setting up the tools

One thing to keep in mind is that Surface is NOT a full ‘desktop’ machine and runs on an ARM processor.  This means to that you cannot install Visual Studio directly on the Surface RT device.  You will need to still ensure that you have a full development environment set up.  But the first thing you will need is to get the remote developer tools for Visual Studio *for your target remote device* architecture.  For Surface RT, this is the ARM tools.

You can get them here: Microsoft Visual Studio Downloads.  Scroll down a bit and look in the “Additional Software” section.  Grab the Remote Tools for Visual Studio 2012 section. 

Remote tools for VS download

You can do this either from the desktop browser on the Surface or from your own desktop and download the remote tools for ARM to a USB key.

On your device, install the remote tools for ARM.  No other Visual Studio installation is required here.  Just run the installer.  When completed you should have a tile on your screen for the tools:

Remote Debugger tile

Now you can get started with your remote debug session!

Configuring the Remote Debugger

After install go ahead and launch the Remote Debugger on your device.  You’ll be presented with (maybe after some firewall questions you need to authorize) the remote debugger now running and in default mode:

Remote Debugger launched

By default, it is set up secure.  This means that in order to attach a remote session you’d need to ensure permissions are correct, etc.  Now since your ARM device isn’t likely on the same domain/workgroup as your developer machine this may be tricky.  Personally, I turn off the authentication options to make my developer experience smoother.  Now of course, you shouldn’t leave your device in this state, but you can close the remote debugger when complete.  Here is the config that I use on my remote debugger:

Remote Debugger config

This allows me to just launch the app on the remote machine without having to use any special authentication tricks since the machine isn’t on my domain, etc.  My remote environment is now set up and ready for me to launch an app and start debugging!

Launching an App on the remote debugger

Now that your remote device is configured and listening, you want to start your app and debug remotely.  Once you have your app in Visual Studio you’ll want to change your launch target to “Remote Device” in the IDE.  This is in the toolbar or in the project properties.  For a C# application it looks like this:

Select Remote Machine target

Once you launch that you’ll be able to select your device.  Now if you are on your home network, with no domains and all on the same subnet, you may just be able to discover your device in the remote debugger connections window.  However you can also just specify the machine name.  Be sure to match the authentication method in this window with what you chose when you set up the remote debugger…in my case “none.”

Remote Debugger connections window

Now that the configuration is there (and selected), when I run (F5) the application it will attempt to deploy it on the remote device.  When you run you’ll notice the remote debugger will show the connections:

Remote debugger connected window

And in your developer workstation you’ll be able to set breakpoints, investigate watch parameters, etc.  All the same stuff you normally do is still available to you.

Summary

Now that you have a Surface (or other Windows RT device) running on an ARM processor, this remote debugging toolset/workflow will be important to you.  The great thing is that once it is set up and you understand the flow, it is very simple and seamless to use.  This presents a great opportunity for you to debug and profile your apps on Windows RT to see any areas that you might be able to optimize for the target device.  And all you need is Visual Studio Express for Windows 8 (free) and the Remote Debugger tools for Visual Studio 2012 (free)

Hope this helps!

| Comments

Saw some posts today over at Don’s site about Surface.  The Surface SDK is starting to get more visible whereas before it seemed a little black-boxish to me.  Turns out (as we all knew) it really is just WPF with some unique Surface-like behaviors in the SDK.  Take this quick demonstration from a program manager on the SDK.  With using the same concepts that we use in WPF and Silverlight for data binding, etc. you can come up with a quick application using the inherent gesture support from a Surface device:

Pretty cool huh?  Same XAML concepts we apply in current work today, but instead of StackPanel, you add a ScatterView and boom, you get some of that simiplistic gesturing support.  Now I know we aren’t all running out to create a photo album viewer to stretch photos, but it’s a good demonstration of some of the simplicity in the SDK.  I kinda wish the ScatterView was actually a Silverlight control :-)

Regardless of your views on politics, here’s an implementation of Surface that MSNBC is starting to use in their newsroom.  I think this is a great use of the device and SDK…it shows a great use-case scenario (and the guy seems to be having fun with it)

Anyhow, I thought these were some great examples of the SDK and a non-entertainment/media) app in use.