API changes for Windows 8.1 Preview(Windows Store apps using C#/VB/C++ and XAML)

[This documentation is preliminary and is subject to change.]

This document lists API removals, functional changes, and optimizations introduced for Windows 8.1 Preview. For other migration resources, see:

• Upgrading your app from Windows 8 to Windows 8.1 Preview–Get started with migrating your app from Windows 8 to Windows 8.1 Preview, from start to finish. Includes best practices, deprecations, and guidance on resubmitting your app to the Windows Store.
• New APIs and features for developers–Get to know Windows 8.1 Preview by looking at new APIs and features.
• Retarget your Windows 8 Store app to Windows 8.1 Preview–Step-by-step guidance on how to migrate your app from Windows 8 to Windows 8.1 Preview.
• Updated samples–Samples for Windows 8.1 Preview that demonstrate how to use new APIs and features, and how to mitigate deprecations.
• DirectX programming–New features and improvements for games and graphic apps.

Important  For more information on API changes in Windows 8.1 Preview related to programming with JavaScript and Internet Explorer, see API changes for Windows 8.1 Preview (Windows Store apps using JavaScript and HTML).

Noteworthy items

These API changes have the highest impact on app migration:

Functionality changes and optimizations

We’ve made significant changes and optimizations, to improve apps in Windows 8.1 Preview. These optimizations include changes to the XAML UI control, a new window size model, .NET profile changes, and more. You'll notice many optimizations without having to change your code, but some improvements do require changes. We encourage that you move away from deprecated APIs, to get the best performance from their app.

Background tasks infrastructure

In Windows 8, the background tasks infrastructure doesn’t perform an early validation of parameters. Parameters are validated later, when the infrastructure tries to run the background task. The error surfaces only as an entry in the event log, causing poorly developed and tested apps that find their way into the Windows Store.

We’ve changed this in Windows 8.1 Preview. The background tasks infrastructure validates parameters up front and returns a failure if they are invalid. You get immediate feedback of the problem. However, pre-existing apps simply crash and the experience escalates from partially broken to fully broken. In that case, we provide an event log.

Performance improvement of C# references

We have improved the performance of apps in Windows 8.1 Preview by increasing garbage collection (GC) speed in C# apps. During GC, the GC implementation gets information from XAML about its object references. The CPU time required is dependent on the number of XAML/C# inter-references (RCWs and CCWs). This change greatly reduces the number of these references.

But apps can see this change because of the way C# weak references work with Windows Runtime (WinRT) objects. C# weak references in both Windows 8 and Windows 8.1 Preview can get prematurely disconnected from a WinRT object, indicating that the object has been deleted when in fact it has not.

If you are affected by this while you migrate your app to Windows 8.1 Preview, you'll see C# weak references go null when they were live before.

Portable Class Library

The Portable Class Library is available only for Microsoft Visual Studio Professional 2013 Preview. It is not available in Microsoft Visual Studio Express 2013 Preview for Windows.

Present core window upon activation in apps that create multiple core windows

In Windows 8.1 Preview, when the user switches to an app, the app presents the core window associated with the thread that receives app activation calls. Windows 8 apps presented the core window that was most recently presented. To return to Windows 8 functionality, call the Windows.UI.ViewManagement.ApplicationViewSwitcher.DisableShowingMainViewOnActivation method.

Quick restart after closing

In Windows 8.1 Preview, if the user closes an app and then immediately restarts it, the closed app is given up to five seconds to complete its termination before it restarts. In Windows 8, the app terminates immediately upon restart.

"Surface all errors" feature

In Windows 8.1 Preview, errors raised in event handlers now propagate. Errors that are unhandled trigger application termination. Before termination, the CoreApplication::UnhandledErrorDetected event fires, giving the developer the opportunity to handle the error without termination. Note that this event does not replace the XAML UnhandledException event. Unhandled errors in Windows Store apps using XAML raise both of these events and the developer is free to use whichever one is better suited to the app.

Suspension occurs at low priority

To improve system responsiveness in Windows 8.1 Preview, apps are given lower-priority access to resources on suspension. The suspension timeout is extended by a corresponding amount so that the app has the equivalent of 5 seconds at normal priority.

Visual C library changes

Here are the VCLibs changes:

• assert() will cause a pop-up message box only in debug versions of the new C++ runtime. Both still break when a debugger is attached, causing issues during Windows App Certification Kit testing for the Windows Store C runtime.
• exit() and std::exit() may no longer exit an app. If these are called in the activation handler they will throw runtime exceptions.
• OpenMP removed support for environment variables and displays errors to the console, causing issues during Windows App Certification Kit testing for the Windows Store C runtime.

WebView control moved to windowless hosting

In Windows 8 apps, the WebView control hosts web pages using the Web Platform in an HWND. Because we deprecated this control in Windows 8.1 Preview, we’re moving from windowed hosting to windowless. This optimizes controls such as clipping, transforms, transparency, and z-order. For example, a WebView control occludes the app bar in Windows 8.   The following would show the WebView in Windows 8 but a rectangle in Windows 8.1 Preview:  

<Grid >
   <WebView x:Name ="wv1" Width="800" Height="800" />
   <Rectangle Width="800" Height="800" Fill="Green"></Rectangle>
</Grid>
 

And if an app has set the Opacity or Clip or Transform on the WebView, it is ignored in Windows 8, but will have an effect in Windows 8.1 Preview.

Window size model

We’ve added a new window size model in Windows 8.1 Preview to support richer multitasking scenarios. The concept of discrete view states is removed and the snapped state is no longer required. Instead, apps can be sized continuously to any size down to their minimum size. An app can either have a minimum width of 500px or 320px. By default, the minimum size of an app is 500px.

The Windows 8 ApplicationView.Value property and ApplicationView.TryUnsnap method are deprecated, so you will receive compiler warnings if your app uses them. An app should register for the window resize event to know when to update the layout. However, instead of calling ApplicationView.Value to find out which view state the app is in, the app developer should apply media queries for window size directly to make layout decisions. In Windows 8.1 Preview, it is up to the app designer to decide what window size thresholds and media queries the app makes to update the app layout.

Windows.ApplicationModel.Resources namespace

In Windows 8, the Windows.ApplicationModel.Resources namespace has just one “immersive monitor” at a time that could show the Windows Store app UI. In Windows 8.1 Preview, the Windows Store app UI can be shown on multiple monitors, with the option to show one app on multiple monitors simultaneously. For scaling, consider multiple scale factors at once.

Windows.Globalization.Fonts namespace

LanguageFontGroup class

The LanguageFontGroup class will return font group data to match the target operating system for which an app was developed. This means that if you update your Windows 8 app for Windows 8.1 Preview, the fonts used in your app may change and you may need to make adjustments to your UI layout.

Windows.Graphics.Display namespace

DisplayProperties class

Some of the DisplayProperties members are deprecated, but new ones have also been added. This change will cause build errors and warnings. If apps use this class and have multiple windows, they may get the wrong resources. If they follow the scaling guidelines for setting explicit width and height of elements, this should work fine other than perhaps blurry images. Apps should be resilient to loading the wrong resources using resource packs in Windows 8.1 Preview. If you are using the display properties API, add some logic to get “for current view” version of the objects into the right place, especially for background threads.

Windows.Media.PlayTo namespace

PlayToConnectionErrorEventArgs class

When apps that use the PlayToConnectionErrorEventArgs object for "Play To" failures, troubleshooting is difficult because the PlayToConnectionError enumeration is not informative. In Windows 8, apps receive the Error event with the Code value always set to DeviceError. In Windows 8.1 Preview, the Error event's Code value is set to either DeviceError or ProtectedPlaybackFailed. This enables the app to determine if the failure is related to the media-protection status of the content, and the app can decide either to continue playing the next item in the playlist or to stop. Apps could also use the new Code value to remove all protected music from the playlist, and so on. Apps compiled for Windows 8 might not work correctly if the error code is set to ProtectedPlaybackFailed. Continue to use DeviceError instead of ProtectedPlaybackFailed error for Windows 8 apps.

Windows.Storage namespace

StorageFile.GetThumbnailAsync method

There are two updates to this method:

• In Windows 8, the GetThumbnailAsync method has just one “immersive monitor” at a time that could show the Windows Store app UI. In Windows 8.1 Preview, the Windows Store app UI can appear on multiple monitors, with the option to show one app on multiple monitors simultaneously. For scaling, consider multiple scale factors at once.

• In Windows 8.1 Preview, this method can return any size thumbnail, so apps that display local pictures should call this method to get the scaled image they want to display. This ensures that apps benefit from all cache and perf optimizations, including a special mechanism to obtain thumbnails from the cloud without downloading the full file.

Windows.UI.Core namespace

CoreDispatcher.ProcessEvents method

Windows 8 apps call the CoreDispatcher.ProcessEvents method to start processing events. However, apps could call this method again from an event handler to simulate their own nested message loop. In Windows 8.1 Preview, calling this method recursively and entering a nested message loop causes the app to fail with an explicit error. To avoid app compatibility problems, this functionality is enabled only for apps compiled and tested for Windows 8.1 Preview.

In general, Windows Store apps using XAML and Windows Store apps using JavaScript should use this method because it is called by the framework on behalf of the app. The CoreDispatcher.ProcessEvents call will fail if called recursively. When this call fails, it uses the RoOriginateError API to report an error and to send an informative string to an attached debugger.

CoreDispatcher.AcceleratorKeyActivated event

XAML processes Ctrl+Tab or Ctrl+Shift+Tab key presses for tab navigation, and apps do not get a chance to handle them from the AcceleratorKeyActivated event. In Windows 8.1 Preview, we will allow the tab navigation processing with Ctrl+Tab or Alt+Tab or Shift+Tab. If you handled the AcceleratorKeyActivated event in Windows 8 to do special processing, the event will get fired for Tab keys when invoked with Ctrl, Alt, or Shift modifiers in Windows 8.1 Preview. Verify tab navigation with Ctrl+Tab or Alt+Tab or Shift+Tab key.

Windows.UI.Core.AnimationMetrics namespace

PropertyAnimation class

Windows Store apps using XAML can animate properties (like width from 0 to 100 pixels over 1 second) by using the PropertyAnimation class. They can also replace one animation with another animation before the first finishes. The second animation can start from wherever the old animation was at the point of the change. The issue in Windows 8 is that this animation handoff value is determined at the time the app changes the animation, but typically animation changes don’t actually take effect until a few milliseconds later, on the next tick. So there’s a user-visible jerk when the animation changes. This is fixed in Windows 8.1 Preview. The second animation still starts from where the first animation left off, but this handoff value is now recalculated at the time of the tick.

Windows.UI.Xaml namespace

Application.LoadComponent method

Apps can define resource dictionaries (key/value pairs) in markup. During markup loading, those dictionaries are created and loaded with actual objects. In Windows 8.1 Preview, resource dictionaries aren’t fully created any longer during markup loading. Instead, the dictionary items are deferred until something in the application actually references it.

This is a performance optimization, because applications frequently have large dictionaries from which many keys are not referenced. Apps have visibility to this change, because apps can observe when dictionary items are created. If dictionary items include application classes, the application sees its constructor execute. Additionally, dictionary items are created in a different order from Windows 8.

Correcting focus navigation in XAML list controls

There are several XAML controls for showing lists of items (ListView, FlipView, and others), and you can write such controls as well. In Windows 8, when the user tabs keyboard focus to the list control, and focus goes to the wrong item, it either stays there or goes automatically to the correct item. This is changed in Windows 8.1 Preview to always go directly to the correct item. This is observable to the app because of focus-change events. An app can determine that focus goes to a difference place now, and that one less focus event is being raised.

Event tracing for Windows (ETW) events

In Windows 8, XAML traces ETW events in its compositor. In Windows 8.1 Preview, we replace that in-process compositor with DirectComposition, so those ETW events are no longer raised. Do not consider adding or removing traces a compatibility issue.

FrameworkElement class

DataContext and LayoutUpdated events

In Windows 8, on the DataContext and LayoutUpdated events, if an app attaches two listeners to it and then removes one of them, both listeners actually get removed. We changed this in Windows 8.1 Preview to correctly remove just the one listener. This change is apparent to the app because in this scenario, the app’s event handler is now called when it wasn’t before, putting the app into an untested code path. Fix any issues in this path. The Windows 8 functionality is the same for apps that have a dependency on listeners.

VerticalAlignment and HorizontalAlignment properties

In Windows 8, the header properties in the ItemsPresenter object was always left or top aligned and you could not specify a different alignment such as stretch or right. We fixed this in Windows 8.1 Preview to honor the VerticalAlignment and HorizontalAlignment properties set on the header.

FrameworkElement.BaseUri property

The FrameworkElement.BaseUri now lets an app query the Uri of the XAML file from which the element was loaded. This could break an existing app that’s worked around the problem by putting their XAML resources in the location identified by the default value.

UIElement.ManipulationMode property

The ManipulationModes enumeration allows multiple bits to be combined. In Windows 8, there’s an exception that the ManipulationModes.System flag can’t be combined with any other flag. This validation check happens when setting the ManipulationMode property. In Windows 8.1 Preview, we fixed this limitation so that the flag can be combined with other flags. If an app combines flags, it will get an error when running on Windows 8, but no error when running on Windows 8.1 Preview.

Note  It’s possible for this change to break a Windows 8 app, because the app might be handling the error.

UIElement.ManipulationStarting event

The ManipulationStarting event is designed to be fired when an input manipulation, such as a tap or a drag, starts. But it doesn’t get fired when there are two manipulations in a row, like two taps in a row, or a tap followed by a pan. We fixed this in Windows 8.1 Preview, to fire the ManipulationStarting event correctly. Apps will see a new event firing, which could put them into an untested event-handler code path.

UIElement.RightTapped event

When the user taps the Properties on a WindowsWindows keyboard, it generates a VK_APPS key event in Microsoft Win32, which XAML translates to a UIElement.RightTapped event. The event args in that event provides the current X/Y position of the pointer. The issue in Windows 8 is that the X and Y values are reversed, so the change for Windows 8.1 Preview is simply to fix the ordering.

So don’t swap the X/Y values anymore. If your app has been impacted by this in Windows 8, it’s likely that you’ve worked around it by swapping the values. Remove the workaround, and validate X and Y position values on RightTappedEvent via the KeyUp event (VK_APPS).

VisualState class

Windows has an accessibility feature under Ease of Access to turn off distracting animations (Turn off all unnecessary animations when possible). XAML has features for transition animations that are considered unnecessary. In Windows 8 you had to handle this case, and it was easy to miss it or implement it incorrectly. So in Windows 8.1 Preview, XAML transition animations handle this scenario automatically.

There are three transition animation features in XAML, and for two of these this change is visible. The three transition features are theme transitions, theme animations, and visual transitions. If you use a transition for a non-transition scenario, you'll need to find another solution. For example, move an animation from a VisualTransition to a VisualState.

If you have animations that are hard-coded to align with a visual transition or theme animation, you must adjust your timing for the cases where animations are disabled.

Windows.UI.Xaml.Controls namespace

Controls view is missing parts when filtered

Parts of the XAML element tree do not show up in the filtered Controls view in the UIA automation tree. We fix this in Windows 8.1 Preview by including more elements in the Controls view. However, some elements showing up in the Controls view shouldn’t be there. The new property, AccessibilityView property, can be set on XAML elements, which lets an app developer specify elements that shouldn’t be in the Controls view. We updated built-in XAML controls in Windows 8.1 Preview to use the new property as appropriate. If a Windows 8 app has custom controls, or custom templates for the built-in controls, these need to set the new property.

ComboBox.MaxDropDownHeight property

In Windows 8, the ComboBox.MaxDropDownHeight property is ignored. Instead, the screen height is always used for the drop-down popup window. In Windows 8.1 Preview, this property is no longer ignored. If this property is incorrectly set, Windows 8 apps running in Windows 8.1 Preview could crash. For example, if you set this property to zero, it will still open on Windows 8, but will simply not open on Windows 8.1 Preview.

Control.OnManipulationStarting method

This method is called before the UIElement.ManipulationStarting event occurs, so this method is affected by the event’s change in Windows 8.1 Preview.

Control.OnRightTapped

Affected by the change to the UIElement.RightTapped event.

GridView.CanReorderItems property

XAML’s GridView controls uses the CanReorderItems property to tell the control if it should allow the user to rearrange the items in the list. The fix in Windows 8.1 Preview is to block the keyboard when the property is set. This is unlikely to break, and more likely to fix apps in Windows 8.

ItemsControl.GroupStyle class

Three properties of the GroupStyle class for ListView and GridView are deprecated and ignored. The properties Panel, ContainerStyle, and ContainerStyleSelector of GroupStyle are no longer honored when ItemsPanel is an ItemsStackPanel. ListView and GridView will be laid out like a traditional list—from top to bottom. Thus, the layout or appearance of items within a group could change in a Windows 8 app that is recompiled for Windows 8.1 Preview if the app does not explicitly set ItemsPanel but set Panel, ContainerStyle, and ContainerStyleSelector. An app that has taken a dependency on the internal structure and types of default ListView objects can crash because the type of ItemsPanel will change and GroupItems will not be created when GroupStyle.Panel is an ItemsStackPanel. This crash would most likely occur when walking the visual tree.

Avoid this by setting ItemsPanel back to the Windows 8 panel (VSP) or removing assumptions about the visual tree structure.

ItemsControl.ClearContainerForItemOverride method

In Windows 8.1 Preview, we improve the work done in the ItemsControl.ClearContainerForItemOverride (CCFIO) method by changing the order in which it must be done. The method does no work until the UIThread is idle, and any pending work queued by CCIFO doesn’t need to be done for calls to PrepareContainerForItemOverride (PCFIO) before the clear work has been done.

Because the work done in CCFIO is expensive and largely unnecessary, XAML ItemsControl objects create containers only for the elements that are displayed on the screen, plus some buffer. These containers are reused as the elements on the screen change, like when a user pans a ListView. When an item is reused, CCFIO is called directly before PCFIO to ensure that the data from the previous element has been cleared before PCFIO populates the container with new info. Clearing the container is unnecessary since PCFIO will overwrite all of the fields. CCFIO takes about 12% of the total time while panning. Doing the work of CCFIO during idle time allows the framework to cancel this work when it is not needed. Not doing the work of CCFIO allows the framework to reclaim 8% to 12% of the time spent panning.

This changes the order in which code is executed. Now the call can return but the container may not be cleared.

ItemsControl.ItemsPanel property

The default ItemsPanel property is changed in Windows 8.1 Preview. In Windows 8, the default ItemsPanel for ListView is VirtualizingStackPanel, and the default ItemsPanel for GridView is WrapGrid. In Windows 8.1 Preview, those defaults are now ItemsStackPanel for ListView and ItemsWrapGrid for GridView. This change may cause crashes when walking the visual tree. The workaround is to set the ItemsPanel property back to the Windows 8 default value.

Image.ImageOpened event

Starting in Windows 8.1 Preview, XAML will automatically reload images when the display scale changes. The typical way to change the display scale is to move an app to a different monitor. Reloading images for this case allows the app to include scale-specific image assets and have those assets be used automatically at the right time. This change occurs in the ImageOpened event.

There are several issues that could affect existing apps. Because we re-fire image events (ImageOpened/ImageFailed) when the image automatically reloads, existing apps may not expect these events to be fired at that time. Also, some existing apps may have manual image-reload logic that would collide with the automatic reload. These changes are visible when migrating apps to Windows 8.1 Preview, but you don’t need to do anything to mitigate their effects.

Image.ImageFailed event

See Image.ImageOpened event.

ListViewBase.CanReorderItems property

XAML’s ListView controls uses the CanReorderItems property to tell the control if it should allow the user to rearrange the items in the list. The fix in Windows 8.1 Preview is to block the keyboard when the property is set. This is unlikely to break, and more likely to fix apps in Windows 8.

MediaElement class

The layout functionality of the XAML MediaElement in Windows 8 is inconsistent. It reports different sizes depending on:

• The type of its parent element
• The size of the media that is playing
• The stretch mode

Because transport controls and the poster image refer to the layout size, this can cause them to display off-screen or be clipped in various cases.

Here are some of the issues this causes:

• MediaElement can be wider than the widest XAML layout.
• MediaElement.ActualHeight returns different values when hosted inside a StackPanel versus a Canvas.
• Transport controls are not visible when playing audio content.
• MediaElement inside a canvas doesn't redraw when width or height is changed.
• Transport controls are not visible for audio content unless height and width is explicitly set on the MediaElement.

In Windows 8.1 Preview, we made MediaElement lay out like other XAML controls, using sizes and restrictions from the layout system rather than from the natural size of the media. You can see different ActualWidth and ActualHeight values, and may need to adjust the app's layout to account for the new sizes. The new sizes are more consistent than the old ones in that the respect the explicit width and height set on the MediaElement, so they are easier to use than the old sizes.

Migrating from IFRAME to WebView

In Windows 8.1 Preview, XAML WebView control can only receive Windows.External.Notify messages from websites that are on the ApplicationContentURI rules and are using HTTPS. These messages are received by the app if it handles the ScriptNotify event.

IFRAME elements within Windows Store apps using JavaScript and not within WebView controls can’t navigate to HTTP websites. An IFRAME can navigate only to packaged content or HTTPS URIs listed in the ApplicationContentURI rules. WebView can support HTTP, but not the following:

• Geoloc
• Programmatic Clipboard
• AppCache
• IndexedDB

Move from windowed WebView control to windowless

In Windows 8.1 Preview, the WebView control in Windows Store apps using XAML and Windows Store apps using JavaScript are windowless and participate in the z-order for apps. The app bar and pop-ups can appear over the top of the WebView control. Apps that used WebViewBrush to work around this limitation should remove that workaround.

This change affects Windows Store apps using XAML in Windows 8.1 Preview, and Windows Store apps using JavaScript that use the new WebView control. Windows 8 apps are unaffected, and the existing windowed mode is used.

Process for building GridViewItem and ListViewItem control templates

All UIElement objects in the default control templates for GridViewItem and ListViewItem have been removed to significantly improve performance in Windows 8.1 Preview apps. Draw default ListView or GridView item templates instead of UIElement objects and retemplate the control. The visuals which currently compose the control template and visual states will be drawn with internal primitives that are invisible to the developer. GridView and ListView controls require each item to provide several visible user interface components, such as the selection checkmark and focus borders. In Windows 8, GridViewItem and ListViewItem satisfy these requirements by using a complex ControlTemplate including tens of discrete UIElement objects and an extensive set of VisualState and Storyboard objects. The parsing and creation cost incurred by these elements has been found to result in unacceptable startup costs.

In Windows 8.1 Preview, each item eliminates the entire control template and interfaces directly with the renderer to provide the necessary UI, rather than going through the normal UIElement abstraction. Doing so yields a large improvement in startup performance. All apps compiled for Windows 8.1 Preview that contain a GridViewItem/ListViewItem with default item templates will see a large startup improvement from the removal of UIElement objects in the templates. We advise developers to apply a Windows 8 template to the ListView or GridView, or remove assumptions about the structure of the visual tree.

ScrollViewer class

This change affects XAML files in the VisualTreeHelper class.

The internal ScrollViewer class in XAML normally does nothing. But when the user brings up the on-screen keyboard (blocking the bottom part of the window) this ScrollViewer class enables panning the window around in the space that is left above the keyboard. The ScrollViewer is not part of the app code, but put in place automatically by XAML at run time.

In Windows 8, this ScrollViewer is a heavyweight solution, and thus affects startup performance. For example, ScrollViewer by default has scroll bars, but in this user experience they’re deliberately disabled. So creating the scroll bars and the things the scroll bars create is a waste of startup time.

In Windows 8.1 Preview, we replace the ScrollViewer with a smaller, lighter control. Implicit styles and the VisualTreeHelper class expose this control in Windows 8. If you are looking at the internal ScrollViewer with VisualTreeHelper, that code path in the app will probably break. Similarly, if the app is configuring the root ScrollViewer with an implicit style, you will see that those changes no longer have an effect. Simply remove that functionality.

New Direct Manipulation track pad gesture support

In Windows 8.1 Preview, Direct Manipulation has added support for track pad gestures. The ScrollViewer class is being updated to use this, and as a result apps will no longer see UIElement.PointerWheelChanged events that they would have in Windows 8.  

SwapChainBackgroundPanel class

The SwapChainBackgroundPanel class is a XAML visual that lets you show XAML controls on top of a DX swap chain. If a SwapChainBackgroundPanel has less than 5 children, and one of those children is moved on screen using its RenderTransform property, it gets visually clipped. In Windows 8.1 Preview there is no clip. An app need not depend on this clip in Windows 8. Bringing up the app bar or app settings Flyout removes the clip.

Textbox.IsColorFontEnabled​ method

In Windows 8, XAML text controls are not able to render multi-color fonts, such as color emoji. For Windows 8 apps in Windows 8.1 Preview, we will enable text controls to support this capability by default. The font that is used to render multi-color characters has different layout metrics for some characters in some cases. This could cause different layout in Windows 8 apps. Text controls in apps (Windows Store apps using C#/VB/C++ and XAML) will not render multi-color fonts until they are rebuilt in Windows 8.1 Preview.

WebView.ScriptNotify event

In Windows 8, the WebView.AllowedScriptNotifyUris and WebView.AnyScriptNotifyUri properties cause the WebView.AllowedScriptNotifyUris and WebView.AnyScriptNotifyUri properties cause the ScriptNotify event to fire. Because these properties are deprecated in Windows 8.1 Preview, the ScriptNotify event can’t be inspected during app onboarding and allows an app to easily put the real work of their app on the web instead of in their app package. Instead, check the package’s ApplicationContentUriRules from the manifest. During app on-boarding, the app can inspect the manifest, which can’t be modified at run time.

Windows.UI.Xaml.Media namespace

ImageBrush.ImageSource property

XAML markup files can make relative URI references to resources within the app’s package. The URI is relative to the markup file’s location within the package.   In Windows 8, in some configurations, the relative URI is composed incorrectly and the absolute URI points to the wrong place in the app package. Primarily, the issue is that app markup files sometimes resolve resources to a component’s resource section.   With the ImageBrush.ImageSource property, apps in Windows 8.1 Preview will resolve URIs to the correct location in the app package.

VisualTreeHelper class

In Windows 8, the VisualTreeHelper class validates calls from a UI thread. But it doesn’t validate that the caller was calling on the correct UI thread. In Windows 8.1 Preview, we changed the VisualTreeHelper class so that it validates that the caller is calling on the correct thread, by letting an app walk and probe the XAML tree.

Windows.UI.Xaml.Media.Animation namespace

The following classes are affected by the change in the VisualState class:

Storyboard.GetCurrentState method

This method returns the state of an animation: Active, Filling, or Stopped. The GetCurrentState method in Windows 8 sometimes returns Stopped when it should return Active. We’ve fixed that issue to return the correct value in Windows 8.1 Preview.

Storyboard.Begin method

Windows Store apps using XAML can animate properties, like changing a width from 0 to 100 pixels over 1 second. They can also replace one animation with another animation before the first one finishes. The second animation can start from wherever the old animation was at the point of the change. In other words, the current value is “handed off” from the first animation to the second. In Windows 8, this animation handoff value is determined at the time the app changes the animation, but typically animation changes don’t actually take effect until a few milliseconds later. So there’s a user-visible jerk when the animation changes. This is fixed in Windows 8.1 Preview. The second animation still starts from where the first animation left off, but the handoff value is now recalculated at the time of the tick.

BeginStoryboard class

Windows Store apps using XAML can animate properties, like changing a width from 0 to 100 pixels over 1 second. They can also replace one animation with another animation before the first one finishes. The second animation will still start from where the first animation left off, but this handoff value is now recalculated at the time of the tick. This change is visible to the app. The app can query the value of the property being animated, and see that after the second animation starts, it doesn’t seem to continue from the initial handoff value.

If you are migrating your Windows 8 app to Windows 8.1 Preview, you might need to change assumptions to allow the animated values to change after a stop.

Windows.UI.Xaml.Media.Imaging namespace

BitmapImage.put_Urisource

The URI validation is removed from the setter in Windows 8.1 Preview. In Windows 8, this property setter performs some validation on the app specified by the Uri argument. But that validation isn’t always necessary and is expensive to perform. If a caller provides an invalid Uri, the problem will still be caught later when the URI is actually used, but that won’t necessarily be during the put_ call.

VirtualSurfaceImageSource ctor

In Windows 8, the VirtualSurfaceImageSource class has parameter validation that allows a maximum size of 100,000,000. In reality, such large sizes don’t work properly. In Windows 8.1 Preview, XAML’s rendering layer is integrated with DirectComposition, and DirectComposition doesn’t allow sizes greater than 16,777,216. The validation limit on VirtualSurfaceImageSource is being reduced from 100 million to 17 million. This change is very unlikely to cause a compatibility problem.

Related topics

Upgrading your app from Windows 8 to Windows 8.1 Preview

New APIs and features for developers

Retarget your Windows 8 Store app to Windows 8.1 Preview

Updated samples

DirectX programming

API changes for Windows 8.1 Preview (Windows Store apps using JavaScript and HTML)

Build date: 7/1/2013