1. Do not use the built in ProgressBar straight up, use Jeff’s template
2. When you’re done with an indeterminate ProgressBar, make sure to toggle IsIndeterminate to False and Collapse the bar
3. General: Always make sure to stop animations / remove animating controls when they’re no longer needed

Some Background:

Due to a bunch of different reasons the shipping ProgressBar control is suboptimal and will actually be UI thread bound – meaning that if your UI thread is stuck working, your ProgressBar will be stuck as well. Not a great situation for a ProgressBar, huh?

That said, we’re not leaving you high and dry. Jeff Wilcox has a great solution which changes the template for the ProgressBar to only run on the Render thread – meaning that it will continue ticking, even when you’re doing your heavy loading work on the UI thread. That said, it still comes with a gotcha – don’t forget to set IsIndeterminate to False and to Collapse the bar once your done (instead of just setting Visibility to Hidden) so that the ProgressBar doesn’t continue to tick in the background, eating up Render thread cycles.

As a general rule, highlighted especially by the ProgressBar, you should always make sure to stop animations (not pause) and remove / collapse animating controls when they’re no longer needed.

Remember: just because you can’t see a animation / control doesn’t mean that it isn’t there doing work.

Tip:

• Test your code on device as much as possible

But the Emulator is awesome?!?

True, the emulator, otherwise known as the x86 Device Emulator, or simply XDE, is awesome, but it is still not an accurate representation of a device. In fact since the XDE is usually so smooth, it’s extremely easy to fall into the trap of adding more features “because it works on the emulator”.

The Hardware

The emulator restricts itself to one core, adds artificial Sleep()’s and limits the amount of memory it is happy to eat up (so it won’t just chew through whatever is available), but that still isn’t enough.Chances are that even running at one core the emulator is still running faster than the device (most cores today are going to be running faster than 1GHz and chances are you are going to have less things running on that core than the device does). Throw in a desktop GPU which beat a mobile GPU handsdown and you’ve got a winning combination. If you happen to have an older machine, then the XDE will simply run like a dog – and you won’t be able to tell if your app crawls because of your code or because of your machine.

But I don’t have a device!

Common problem, especially in these trying, pre-release, times. Fear not though! Your local Microsoft office most likely has some devices and can help hook you up. Shoot them an email and let them know that you are working on an app, include a description and some screenshots from the XDE (to sweeten the deal) and they should be able to help.

What does this mean?

Basically, long TextBoxes will no longer scroll when you gesture over them – the gesture is ignored and there is no visual reaction. Tapping remains the same (the keyboard pops up) as does tapping and holding (the enlarged caret is shown, and you can use this to, sort of, scroll).

How do I work around this?

Most scenarios do not require scrollable TextBoxes, but if your’s does you can either place the TextBox inside a ScrollViewer (though this can cause some texture issues), or preferably re-add the ScrollViewer into your TextBoxes template, so that it still scrolls as usual.

Original Post

Basically, profiling any Silverlight app (plugin or OOB) that takes advantage of Shaders will cause Silverlight (and its container) to crash. The only current workaround is to remove the shaders before profiling (possibly with an #ifdef if you are so inclined). This is slated to be fixed in an upcoming version of SL 4 (though no release dates yet).

Note: people often get scared of crashes since they can indicate a security bug – but this is not a security issue (the profiler puts us into a bad state, causing the crash).

Cross-posted from msdn.

Firefox will shut down a plugin when it is deemed to be either dead, or frozen. Unfortunately frozen is the state that the plugin will enter when you try to debug it (say, through Visual Studio), causing Firefox to kill the plugin and continue on its merry way. There have a been a number of proposed solutions, mainly around disabling the plugin container for Silverlight (see this forum post). Unfortunately, while this works for debugging, this is not a real user situation that you are debugging (since you’re no longer locked in the container, which is the expected state for any user running your app). In order to get Firefox to still run Silverlight in the container, but not kill it when it detects a Freeze, do the following:

1. type about:config
2. find dom.ipc.plugins.timeoutSecs (you can start typing it in the filter)
3. change the value to -1

This effectively cancels the timeout so that even though the plugin is no longer responding to Firefox’s NSAPI messages, it will not be killed.

Happy bug hunting!

The counters currently show up behind the system tray (since technically the tray is a system overlay which is drawing over the surface available to your Silverlight app), so hiding the tray will show the counters.

Don’t forget: to re-enable the system tray when you’re done!

"Switch from current encoding to specified encoding not supported"

and your .AddIn file looks completely normal when you open it in a text editor, then you're most likely not writing your .AddIn file in Unicode. Since the .AddIn usually specifies:

<?xml version="1.0" encoding="UTF-16" standalone="no"?>

Visual Studio expects the file type to be Unicode, so if you wrote your .AddIn file to disk using something like:

File.WriteAllText(addinFile, addInConfig);

You'll need to adapt your code to something like:

File.WriteAllText(addinFile, addInConfig, System.Text.Encoding.Unicode);

To make sure that the file is Unicode.

Hope that helps!

Unfortunately you may notice that if you create a simple WPF UserControl and then try to create a ToolWindow from it using CreateToolWindow2, you’ll run into the following Managed Debugging Assistant:

Managed Debugging Assistant 'NonComVisibleBaseClass' has detected a problem in 'c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe'.

Additional Information: A QueryInterface call was made requesting the default IDispatch interface of COM visible managed class 'WPFUserControlAddIn.WPFToolWindow'. 

However since this class does not have an explicit default interface and derives from non COM visible class 'System.Windows.Controls.UserControl', the QueryInterface call will fail. 

This is done to prevent the non COM visible base class from being constrained by the COM versioning rules.

If you follow through this error message it will lead you to the MSDN page for this error (here) and from there to the page that holds the solution.

The Solution

Add the following to your [yourfile].xaml.cs around your class declaration:

    using System.Runtime.InteropServices;
    using stdole;

    [ComVisible(true)]
    [ClassInterface(ClassInterfaceType.None)]
    class [yourclass] : UserControl, IDispatch

Note! Don’t forget the addition of the IDispatch implementation (there’s nothing to implement, don’t worry). Without it you’ll get "InvalidCastException" from mscordb.lib and a null in your ref object (the last parameter to CreateToolWindow2.

Got a Sample For Us?

You bet – grab the sample solution. All you need to do is extract, add the .addin file to you AddIns directory (under Documents\Visual Studio 2010\Addins) and away you go.

You’ll notice that if you do something like:

<MediaElement Source="somevideo.wmv"/>

Where “somevideo.wmv” is set to “Content”, then the Windows Phone Developer Tools (ie. Visual Studio) will underline the "Source" attribute and recommend that you set it to “Resource”. This is a hangover from the desktop and is something that I hope will go away – you can safely ignore this warning (it won’t appear in your build windows).

What’s Wrong With “Resource”?

For those that want more, here are the potential problems you can run into when setting your media to “Resource”:

1. When a video file is compiled as a Resource it incurs an extra space and performance hit every time you play it, since Silverlight does extra processing to extract the video from your assembly (DLL). In the case of “Content” the file can be read directly from disk (or memory) and you’ll get instant start playback.
2. Anything that makes your DLL larger is evil (from my point of view) – you want your assemblies to be small (think “quick and nimble”). Although the size doesn’t always directly affect load and memory time (there are a couple of other factors at play here) this helps eliminate one more possible bottleneck.

This post is based off the awesome talk that Seema Ramchandani gave at Mix ‘10.

Note: To test these out either open an existing Silverlight application, or start a new one. The screenshots in this post are mostly from the Windows Phone 7 Emulator (XDE) so will vary slightly to the desktop version.

Frame Rate Counters

• Enabling
  Open up App.xaml.cs and add the following bolded line to your App() constructor:
  

  public App()
  {
      UnhandledException += new EventHandler(Application_UnhandledException);
      InitializeComponent();
  
      App.Current.Host.Settings.EnableFrameRateCounter = true;
  }
  

• What you’ll see
  In the top left corner of the screen you should see the following counters:
  

  Silverlight Framerate Counters

  
  Note: On the desktop counter A & B are merged into one counter.

• I don’t see the counters! (mobile)
  This means that you are running without hardware acceleration. Either the machine running the emulator does not support hardware acceleration (DirectX 10 for the early refreshes) or you’ve run into a bug (there are a number of them which are currently being zapped) which has caused your device / emulator to run out of video memory. Restart the device / emulator and you should be right.

  Note: To tell if your emulator supports hardware acceleration (or if your device has run out of video memory) look at your screen as you launch a XAP – if it does the page flip animation then you’re ok, otherwise if the app just appears then you are in software.

• What do they mean?
  I’ve added letters to indicate the different fields as so:

  

  1. Render Thread Framerate (fps) (mobile only)
  2. UI Thread Rate Framerate (fps)
  3. Amount of VRAM used by App (kb)
  4. Total number of textures on GPU
  5. Number of intermediate textures

Redraw Regions

• Enabling
  Open up App.xaml.cs and add the following bolded line to your App() constructor:
  

  public App()
  {
      UnhandledException += new EventHandler(Application_UnhandledException);
      InitializeComponent();
  
      App.Current.Host.Settings.EnableRedrawRegions = true;
  }
  

• What you’ll see
  In this example I’m using the default Windows Phone list application and clicking through the list options and then back with the hardware back button.
  

  Redraw Regions highlighting redrawn areas as we transition between pages

• What am I looking at?
  Redraw regions highlights (tints) every part of the screen as it is redrawn, either due to a user initiated action (say, scrolling a non-cached list box) or some code (animation). Cached Objects that are being animated / moved / scrolled etc (BitmapCache) will not be redrawn, but as soon as the object is modified (say, you change its colour as it moves), it will be redrawn – and you will see this highlighted by EnabledRedrawRegions.

  As regions are redrawn the colours will cycle through Blue, Yellow, Pink (Purple) so that you can see the transition – there is no significance to the specific colours.