| Comments

If you’ve created a Windows 8 app using XAML then you’ve likely seen a file in the project called StandardStyles.xaml in the Common folder and merged in with your application.  As I’ve seen apps developed I’ve seen people pretty much treat this as a system component and not change it at all.  Sometimes that’s good, but mostly it has been bad.  There are a lot of apps that I’ve seen that don’t use a lot of the styles in that dictionary, but don’t do anything to trim the file or even remove it if not needed.

The file was included in Windows 8 Visual Studio project templates to help style some areas of the template.  In looking at performance in Windows 8.1 we saw that people were not removing this file or unused styles in this file.  We also saw that there was benefit to including some of these styles in the framework because of some styles/template deferred loading we implemented in Windows 8.1.  As such for almost all apps we’ve seen in practice, the styles provided in Windows 8/VS2012’s StandardStyles.xaml file can be removed from your application and replaced with styles in the XAML framework.

Text Styles

A big portion of the file is providing some text styles that map to the typographic ramp for the Windows design language.  Roughly 100 lines of text styling can now be migrated to new framework-provided text styles.  Here’s a mapping of what you should examine replacing with in your Windows 8.1 app:

StandardStyles.xaml (in VS 2012)Windows 8.1 XAML Framework-provided name
BasicTextStyleBaseTextBlockStyle
BaselineTextStylen/a (merged with BaseTextBlockStyle)
HeaderTextStyleHeaderTextBlockStyle
SubheaderTextStyleSubheaderTextBlockStyle
TitleTextStyleTitleTextBlockStyle
SubtitleTextStyleSubtitleTextBlockStyle
BodyTextStyleBodyTextBlockStyle
CaptionTextStyleCaptionTextBlockStyle
BaseRichTextStyleBaseRichTextBlockStyle
BaselineRichTextStylen/a (merged with BaseRichTextBlockStyle)
BodyRichTextStyleBodyRichTextBlockStyle
ItemRichTextStylen/a (was same as BodyRichTextBlockStyle)

 

The replacement is pretty simple as wherever you were using {StaticResource SomeTextStyle} you would now change to {StaticResource FrameworkProvidedStyle} (obviously using the correct names).  As with anything, when making these changes test your app to ensure your UI fidelity remains as you expect.  Should you need to continue to style some of the above, you could use these as your BasedOn starting point.

Button Styles

Another area was a series of Button styles around Back button, TextBlock buttons and the most used AppBarButton styles.  TextButtonStyle is now TextBlockButtonStyle and serves as a styled Button for areas like GridView clickable section headers, etc. 

There were also a few Back button styles.  With the introduction of AppBarButton in Windows 8.1, we can provide a better/specific template style provided in the framework with the right glyphs for the arrows.  Instead of using the BackButtonStyle/SnappedBackButtonStyle in StandardStyles.xaml you should use NavigationBackButtonNormalStyle and NavigationBackButtonSmallStyle.  The normal style is the main one that you would use on pages and is the 41x41px standard back button.  The small style is the 30x30px smaller button that you might use for a narrow (formerly snapped) view or other areas.

Perhaps one of the most used areas were the AppBarButton styles.  There is roughly 1100 lines of styling for a series of button styles for the various popular glyphs of AppBar button styles.  We are now providing a typed button that is optimized for that UI and we now have included 190 icon types as a part of the base.  As an example this is what you might have had in your Windows 8 app:

<Button Style="{StaticResource PlayAppBarButtonStyle}" />

And can now be replaced with:

<AppBarButton Icon="Play" Label="Play" />

This reduces the need for the base AppBarButtonStyle as well as the others that were glyph-specific.  If you need them to be RTL specific, just add the FlowDirection property as you need it for your app.  The Label property will map directly through to the AutomationProperties.Name value by default as well for the accessibility needs.

List/Grid Item Templates/Styles

In the Grid/Split templates there were also style item templates for the use in the pages within these templates.  In looking where they were actually used, these were moved to only the pages that need them.  Many people think that your styles/templates must be in App.xaml, but this is not true and most of the time not a good performance decision.  If your style is only used in one page, put it in the resources of that page!  That is what was done with these specific styles for the VS 2013 project templates.  Some were removed in accordance with new guidance around app sizes as well.

Using Visual Studio 2013 for Styling

You may ask yourself now how you would use this or know about them or even remember them!  Luckily Visual Studio 2013 added some great new features in the tools to bring more visibility to these styles.  The resource pane is still there and would show the framework-provided styles as seen here in Blend:

System Resource style selection image

If you are an editor-only person, there is still great news as VS added Style IntelliSense!!!  As you use StaticResource you will get auto-completion on the styles that apply to that style you are on.  For example on TextBlock you will only see Styles that apply to TargetType=TextBlock as seen here:

VS Style IntelliSense image

This IntelliSense will work with your own custom styles as well and is a great productivity enhancement to the tools.  This one of my favorite new features of VS!

If you want to see the details of these styles you can use the great template-editing features in Visual Studio/Blend to inspect them as well.  Once you have the style you can now also F12 (Go to definition) on the Style itself!!!!  This will take you to the definition of the style in the framework’s generic.xaml:

Style Go to definition example

This is an amazing productivity feature that is available for all Styles in XAML, again including your own!  These styles can be manually inspected by looking at the generic.xaml that ships in the Windows SDK (location %programfiles%\Windows Kits\8.1\Include\WinRT\XAML\Design).

Summary

One of our main goals was continue to improve overall app performance for Windows 8.1 for all users.  This optimization of bringing most commonly used styles into the framework benefits developers for consistency and productivity as well as all users for shared use of these templates and reduced load/parse time for each individual app needing to provide some of these core styles.

Hope this helps!

| Comments

A few weeks ago I had the great pleasure of being in front of you, our developer customers (and friends) at the Microsoft BUILD conference. (I never know how to write “build” in a sentence and refuse to use the “//” in front of it.) These are things that I LOVE doing and wish I could do it more. I had the privilege of introducing an overview of what was new in the XAML UI framework for Windows 8.1. All the sessions are recorded so please go view mine and review it how you think so they might invite me back!

In my session I gave some preview of some of the great new XAML tooling that is introduced for developer productivity in Visual Studio 2013 which, as of this writing, is currently in preview form and available for download. My colleague Unni followed my session with one specifically about XAML tooling enhancements with a whirlwind tour of all the new features. Please go check out his session: What’s New in Blend and Visual Studio for XAML Developers for the complete details.

One of the things I showed was the introduction of Visual Studio (VS) code snippets for the XAML editor. This was one of the customer requests for a while for the XAML editor and is now available in the VS 2013 preview! In my presentation I showed a common task that I do which is to have many elements and wrap them in a StackPanel. I’ve gotten lazy and wanted a quick ‘refactor’ way to do this and now I can! A few have emailed me asking where the snippet I used was as nothing was working in the preview for them. As of this writing, the functionality was in the preview, however no default XAML code snippets are provided. I’ve responded to a few on an MSDN forum thread offering to share my snippets and someone suggested I post more details, so here it is!

Anatomy of a Code Snippet

Code Snippets in VS are basically XML files that sit in a special location (one of two locations, global or user). These code snippets can apply to many things including languages (C#, VB, etc.) as well as ‘markup’ languages (CSS and now XAML). You can read more in-depth data about VS Code Snippets here. The basics that I think you want to know are the two main types of snippets: Expansion and SurroundWith.

An Expansion snippet is one that you invoke and it gives you placeholders for stuff to fill out. My most widely used one is ‘foreach’ in C#. You start typing foreach, then hit tab-tab and you are presented with a template, more or less, to complete. A SurroundWith snippet is one that surrounds (duh!) the selected content in the editor surface with your template. An example of this is the #region snippet which puts the begin/end region tags around selected code. It is important to note that these can be used exclusively or together. That is to say I can have a SurroundWith snippet that is also an Expansion. In fact, the #region one is a good example: it surrounds the selected code and also gives you a field to complete for the region name. The Code Snippet structure is the same for most languages with the difference being that in the Code node of the snippet definition it defines which language it applies to for the editors.

NOTE: Creating Code Snippets is a very manual process. At the time of this writing there was no really great tool to “extract” a chunk of code and turn it into a code snippet. There are a few attempts out there, but most have been abandoned and not all working.

Once you have these XML files (.snippet files for VS), you place them in well-known locations or can use the Code Snippets manager in VS (more on that later).

XAML Code Snippets

As noted above the XAML code snippets are the same structure as the C# snippets with the difference being the Language attribute on the Code node in the definition. In my demo I used a StackPanel SurroundWith snippet with the following definition:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippet Format="1.0.0" xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <Header>
    <SnippetTypes>
      <SnippetType>SurroundsWith</SnippetType>
    </SnippetTypes>
    <Title>Vertical StackPanel</Title>
    <Author>Tim Heuer</Author>
    <Description>XAML snippet for surrounding content in a vertical StackPanel</Description>
    <HelpUrl>
    </HelpUrl>
    <Shortcut>vsp</Shortcut>
  </Header>
  <Snippet>
    <Code Language="XAML"><![CDATA[<StackPanel>$selected$$end$</StackPanel>]]></Code>
  </Snippet>
</CodeSnippet>

Notice the <Code> element and how it has the Language=”XAML”? That is the only difference between this and a C# one. There are keywords for certain things like selected (which is a marker for selected content) and end (which is where you want the cursor to be at the completion of the snippet) that you can use and are in the documentation. Here is another example of an Expansion XAML snippet for an AppBarButton:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title>AppBarButton</Title>
            <Shortcut>abb</Shortcut>
            <Description>Code snippet for XAML AppBarButton</Description>
            <Author>Tim Heuer</Author>
            <SnippetTypes>
                <SnippetType>Expansion</SnippetType>
            </SnippetTypes>
        </Header>
        <Snippet>
            <Declarations>
                <Literal>
                    <ID>icon</ID>
                    <ToolTip>The Icon value to use for the visual</ToolTip>
                    <Default>Emoji</Default>
                </Literal>
                <Literal>
                    <ID>label</ID>
                    <ToolTip>The text label for the button</ToolTip>
                    <Default>My Label</Default>
                </Literal>
                <Literal>
                    <ID>uniqueid</ID>
                    <ToolTip>The unique ID for the button</ToolTip>
                    <Default>MyAppBarButton</Default>
                </Literal>
            </Declarations>
            <Code Language="XAML"><![CDATA[<AppBarButton x:Uid="$uniqueid$" x:Name="$uniqueid$" Label="$label$" Icon="$icon$" />$end$]]>
            </Code>
        </Snippet>
    </CodeSnippet>
</CodeSnippets>

As you can see they are pretty simple to use!

Adding Code Snippets to VS

There are two ways to distribute snippets: as raw .snippet files or with an installer. You can send someone a .snippet file and they can use the Code Snippets Manager tool to import it into their environment. This is a per-user method. From VS you would use the Tools menu and choose the Code Snippets manager:

<pic>

From here you would navigate to the XAML folder, then choose Import and select your .snippet files. These would then import them into your local profile (Documents\Visual Studio 2013\Code Snippets) and be ready for immediate use. Another way is through an installer. Now up until VS 2013 there was the VSI installer (as documented here on MSDN) which has since been eclipsed by the VSIX extensibility method. Right now there doesn’t appear to be much documentation on this method, but you *can* distribute code snippets via the VSIX installer. VSIX is basically a ZIP file format with a manifest and content. For this purpose the manifest describes the targets and the package definition for the VSPackage we are installing, which is in this case a folder of snippets. This is a little tricky method to get VSIX to use as an installer for snippets, but works. I won’t detail out the entire process here, but leave you with a few screenshots and you can download the file and look at the contents to see how it works…again it is a regular ZIP file so just rename and explore.

Contents of VSIX:

Contents of VSIX package

Installer dialog:

VSIX installer dialog

Once installed your VSIX-deployed snippets show up in the Extension Manager:

Extension manager listing

And there you have it! A simple way to distribute your code snippets. This VSIX can be put on VS gallery as well so that you can update it there and anyone who installed it can get updates from within VS itself!

To actually use the code snippets, from within the XAML editor use the shortcuts CTRL+K,S (for surround snippets):

Surround code snippet

or CTRL+K,X (for expansion snippets):

Expansion snippet

Expansion snippet completed

Summary

Code snippets can be a powerful productivity tool for VS. You probably use them daily (like foreach) and maybe didn’t even realize it! Now that this concept is extended to XAML there are some great opportunities to increase your markup productivity by encapsulating some things that you do often into a XAML code snippet. Right now the VS gallery doesn’t support uploading the method for VSIX that I have described so you can download my VSIX for some code snippets examples here for now.

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

This week was TechEd North America, a conference from Microsoft for technical professionals covering the span of pretty much everything Microsoft produces to support IT professionals and software developers.  I was pleased to have been invited to speak on developing Metro style apps in XAML for .NET developers.  Like most developer presenters, I planned on showing a lot of demos, using different tools, editors, and varying code samples, URLs, etc.  When you are a presenter at a conference you usually don’t have the luxury of sitting in your office and doing things without distractions.  You want to get across your message of your presentation and also be able to have some good demonstrations articulating your points.  When you have a lot of demos, most of the time presenters will rely on some form of snippets – something for them to either type in quickly, copy/paste, or drag/drop onto editors.

I’ve used various snippet concepts over the years:

  • Using the Visual Studio Toolbox area and dragging text there (yes, did you know you can do that)
  • VS Code Snippets
  • Custom WPF “always on top” snippet utility (developed by a WPF team member when she was doing presentations)
  • Other 3rd party macro tools

But mostly I, like others, have relied on good ol’ notepad.  For each presentation I have a file and just blocks of code separated with headers denoting to me which step the snippet is for in the demonstration.  I don’t always use snippets because I do have some sense of pride in being able to demonstrate yes, I do actually know what I’m talking about and not just always copy/pasting!  However, again, for efficiency and to get many points across, it is an effective way to start from a blank slate (project) and build up how code gets structured for your particular concept.

Notepad has been great and reliable so I’ve always used it.  The other methods are more laborious to set up and sometimes error prone…aside from the fact they don’t work in all scenarios (i.e., VS code snippets don’t work in XAML…argh). 

This week while preparing in the speaker room with my colleague John Lam (who also gave a presentation on the Windows Runtime) he was using a new utility I hadn’t heard of before.  I usually get my little widgets of knowledge from Scott Hanselman’s massive list of tools.  Most I don’t use, but there are some really helpful gems in there.  So I was surprised about this new tool John was showing me I hadn’t heard of before.

YES, I realize this is probably not a new tool and this invites comments of ‘duh, this has been around forever dude’ so feel free to not post those.  It is new to me, like in that new used car kind of way.

When John was walking through his demo he was typing what seemed like random keystrokes in various places: VS, Blend, Notepad, dialogs, command prompt, web apps.  All of these were translating into blocks of text, shell commands, etc.  He lit up showing me about this new tool, AutoHotkey.

AutoHotkey is a very small tool that basically is a mini macro language.  I’m going to completely under-sell it for it’s likely true abilities, but even for the simplest use it has been a new favorite.  AutoHotkey works by listening to the accessibility features in Windows (also referred to UIA) for anything that has input focus.  Yes, that’s right, anything.  You define a ‘macro’ keyword and then what the command defines.  For me, this was just needing to be a series of copy/paste automation.  Here’s an example of one of my snippets:

   1: ; clear clipboard
   2: ^+x::
   3: clipboard = ; null
   4: return
   5:  
   6: ; Initial StackPanel stubs
   7: ::d1::
   8: clipboard = 
   9: (
  10: <StackPanel>
  11:             <TextBlock FontSize="53" x:Name="FirstName" />
  12:             <Button Content="Click Me" Click="Button_Click_1" />
  13:         </StackPanel>
  14: )
  15: send ^v
  16: return

Anything preceded with a semicolon is a comment.  The next line is the macro command it will listen for when input has focus.  In the above there are two “^+x” means CTRL+SHIFT+X.  The command is followed by two colons which is the delimiter for the command.  The simpler one for “d1” shows how you issue a copy/paste.  I tell it what I want to put on the clipboard, then say to send a CTRL+V (paste) and end the script with a ‘return’ statement.

The beauty is that there is no “app” that you have to run – your script is basically the app.  You create your script in a text file named with an .ahk extension.  When your script is complete, double-click on it and it is now listening.  You’ll get an icon in the system tray showing you that it is running and some options (i.e., you can pause it, edit, reload to tweak):

AutoHotkey example

What is cool is that if you want to see how it is working and what it is doing you can look at the “spy” feature:

AutoHotkey spy

to see how it is listening to automation events and input focus. 

The other great feature it has is that you can compile your script.  What this does is take your script (ahk file) and compiles the AutoHotkey runtime into it as well, producing an EXE.  Now you can take that EXE to any machine and double-click and boom, your snippets are available and listening.  So now I can can compile my snippets for each presentation and put them alongside my other presentation materials on my SkyDrive…keeping everything together and quickly restorable to any machine.  Awesome.

I immediately started using it and became an instant evangelist to other presenters that moment.  John Papa used it in his presentation as well and Pete Brown I think is now converted as well.  For me it worked great, no issues. 

Creating the script was a bit of trial and error because the documentation is, well, not great.  It does SO MUCH MORE than what I’m using it for which is why I felt the docs lacking for the simple cases.  The ‘return’ keyword was critical for me to get mine working without error.  When you install AutoHotkey there is also an “Extras” folder that contains plugins for various editors: VIM, Emacs, TextPad, SciTE, Notepad++ and more.  These allow you to get syntax highlighting in these editors quickly.

Thanks to John Lam for turning me on to this. UPDATE: I’m the idiot because it *is* on Scott’s list.  My search wasn’t good enough apparently :-) and maybe Scott Hanselman will consider it for his ultimate tools list this year.  What is also awesome is that there is a Chocolatey installer for it so I just added this to my personal just-repaved-my-machine-please-give-me-my-utilities package.  Be sure to check it out if you find yourself doing a lot of snippets.

Hope this helps!

| Comments

I’ve been working on some stuff around templates lately and had my own opinions of some of the value of certain features of the Visual Studio template functionality.  What I’m speaking of here is when you choose File…New Project or on an existing project Add Item.  Both of those show you a list of templates.  When you select one most typically you get new files in your project.  It is one area of Visual Studio that is the simplest to extend and provide specific templates for your developers.

There is an option for template developers to specify what, if any, files are open by default once the template is added.  Using Silverlight as an example, when you create a new project you’ll see that the default MainPage.xaml file is opened for you in the designer.  I wanted to get a feeling of what developers thought of this functionality.  Help me with some research?

This is, of course, totally un-scientific and I just wanted to get a litmus test of what people thought of that functionality (opening files by default, not just the concept of templates). Thanks in advance for helping out!