04 Dec 2017
04 Dec 2017
04 Dec 2017

Windows 10 Tip: Get started with Continue on PC in the Microsoft Edge mobile app

Author: Elana Pidgeon
Go to Source

You know those websites, searches and articles that you pull up on your iPhone or Android phone? With the Windows 10 Fall Creators Update, you can now forward them to instantly open on your PC, so you can continue what you’re doing – researching that project, shopping for those shoes, finishing that article – with all the benefits of the bigger screen.

Here’s how to get started:

Head to Settings, click on Phone and Add a phone. You’ll need to sign in with your Microsoft Account, if you haven’t already. Type your phone number, and click send.

Continue on PC

Once you click send, you’ll receive a text with a link to the app store to download and install an app.

Now, for a seamless browsing experience across your phone and PC, you can download the Microsoft Edge mobile app for free and try out the Continue on PC feature this way! If you’re looking at a website in the app that you want to continue looking at on your PC, simply find the Continue on PC icon on your iPhone or Android phone. Sign in with the same Microsoft Account you’re using on your PC.

Continue on PC

Next it will ask you if you want to “Continue now” or “Continue later.” If you choose “Continue now,” the website will open on the linked PC. If you choose “Continue later,” the website will show up under Action Center for you to get to later when you’re ready.

Head over here for more on what’s new in the Fall Creators Update, and have a great week!

Go to Source

Share this
04 Dec 2017

Extend your desktop application with Windows 10 features using the new Visual Studio Application Packaging Project

Author: Ricardo Minguez
Go to Source

Visual Studio 2017 15.4 introduced the new Windows Application Packaging project to help you modernizing your application by using the new Windows 10 App Deployment Stack.

We talked about it in our previous post: Visual Studio 2017 Update 4 makes it easy to modernize your app and make it store ready and today we want to describe the new capabilities in Visual Studio 2017 15.5 that enable new scenarios to the Windows application packaging project to take advantage of more Windows 10 features in your applications.

During this article we will cover three examples to highlight the new capabilities added to the packaging project to enable packaging for not only Win32 applications, but also UWP applications and components:

  1. Background execution using UWP background tasks.
  2. Windows Shell integration using the Share Target contract.
  3. Include Win32 code investments in your UWP app package.

The first two samples are existing WPF applications packaged as APPX with extended functionality implemented as UWP components. The first application adds background execution based on UWP background tasks, while the second app shows how to deeply integrate the application with the Windows 10 shell using a widely available feature as Share contracts. Finally, the last app is a UWP entry point that calls to a classic Win32 process that interop with Excel.

Note: Because the UWP components require to be compiled for a specific platform: x86 or x64, the Any CPU solution configuration will not work in any of these samples.

All samples are available in the GitHub repo Windows-Packaging-Samples. These samples require Visual Studio 2017 15.5 Preview 4 or greater, available to download from https://www.visualstudio.com/downloads.

1. WPF with Background Tasks

The Universal Windows Platform includes support for advanced background processing. Background tasks allow running code even when the app is suspended. Background tasks are intended for small work items that do not require user interaction, such as downloading mail, showing a toast notification for an incoming chat message or reacting to a change in a system condition.

To show how to use this feature from your Win32 applications, we are going to implement a small utility that will make an HTTP request to a URL configured by the user and will show the elapsed milliseconds in a Toast Notification.

We will create a WPF application to allow the user to specify the URL to check and enable/disable the background task. The background task will be implemented as a Windows Runtime Component (WINMD). To be able to include this component in the package, we need to create a UWP application that uses the component, and finally add the WPF and UWP projects as references to the packaging project. Below is the list of steps needed.

You can find the complete source code of this sample in the GitHub repository, but if you want to create the sample from scratch here are the most important steps.

  1. Package your desktop application using the packaging project
  2. Add a Windows Runtime component to implement the background task
  3. Add a UWP application that reference the runtime component
  4. Add a reference to the UWP application from the packaging project
  5. Configure the Background task in the manifest
  6. Register the background task from the Desktop application

Once you completed steps 1 to 4, you should have a solution for projects as shown in the image below:

The packaging project references not only the WPF application, but also the UWP project. For this reason, the solution needs to be configured for a specific platform, since UWP is not available for Any CPU configurations.

Background Task implementation

The background task is a C# class that implements the IBackgroundTask interface. This interface defines the Run method that will be called when the system triggers the task.

public sealed class SiteVerifier : IBackgroundTask
    public async void Run(IBackgroundTaskInstance taskInstance)

        taskInstance.Canceled += TaskInstance_Canceled;
        BackgroundTaskDeferral deferral = taskInstance.GetDeferral();
        var msg = await MeasureRequestTime();

    private async Task<string> MeasureRequestTime()
        string msg;
            var url = ApplicationData.Current.LocalSettings.Values["UrlToVerify"] as string;
            var http = new HttpClient();
            Stopwatch clock = Stopwatch.StartNew();
            var response = await http.GetAsync(new Uri(url));
            var elapsed = clock.ElapsedMilliseconds;
            msg = $"{url} took {elapsed.ToString()} ms";
        catch (Exception ex)
            msg = ex.Message;
        return msg;

Note how we use the LocalSettings in ApplicationData to share information between the WPF application and the UWP background task.

To configure the background task, you need to update the manifest using the manifest designer. Go to the declarations tab, add the background task and configure the entry point as the implementation.

To register the background task in the system, we need to call a Windows 10 API from the WPF application. This API is available in the Windows 10 SDK, and to use it from .NET we need to add the references explained here. Once you have access to the Windows 10 API you can use  the BackgroundTaskRegistration class to configure the background task as shown in the code below:

public void RegisterBackgroundTask(String triggerName)
    var current = BackgroundTaskRegistration.AllTasks
        .Where(b => b.Value.Name == triggerName).FirstOrDefault().Value;

    if (current is null)
        BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
        builder.Name = triggerName;
        builder.SetTrigger(new MaintenanceTrigger(15, false));
        builder.TaskEntryPoint = "HttpPing.SiteVerifier";
        System.Diagnostics.Debug.WriteLine("BGTask registered:" + triggerName);
        System.Diagnostics.Debug.WriteLine("Task already:" + triggerName);

To register the background task, first we make sure the task has not been registered before, and then we use the BackgroundTaskBuilder to configure the name and the Trigger, in this case we are using the MainteinanceTrigger.

2. Register your application as Share Target

Share contracts is a Windows 10 feature that allows the sharing of information between two apps, the sender and the receiver. Thanks to the Desktop Bridge, we can register a UWP application as a Share receiver and then integrate with a Win32 application. Once the app is registered, it will be shown every time the user invokes a share operation as shown below:

In this sample, we are extending a WPF application to become a share target where users can send images from other apps like the Photos app, Edge or even the Shell to our application. We are using the packaging project to include not only the WPF application, but also a UWP application that allows a UWP UI to receive events from the share target. Below you can see the solution explorer with the packaging project referencing the WPF and UWP projects.

The package needs to declare the Share Target, including the name of the UWP application:

When the application gets activated, it receives the share target information from the ShareOperation parameter as shown in the code snippet below:

protected async override void OnNavigatedTo(NavigationEventArgs e)
    operation = (ShareOperation)e.Parameter;
    if (operation.Data.Contains(StandardDataFormats.StorageItems))
        var items = await operation.Data.GetStorageItemsAsync();
        file = items[0] as StorageFile;
        IRandomAccessStreamWithContentType stream = await file.OpenReadAsync();

        await this.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, async () =>
            BitmapImage image = new BitmapImage();
            this.img.Source = image;
            await image.SetSourceAsync(stream);

Now every time the user shares a picture and selects our application, the Share UI application gets invoked and the UWP UI will be displayed.

After clicking the “Share to WPF app” button, the UWP will process the event handler, and will copy the picture to the ApplicationData folder and run the Win32 application using the FullTrustProcessLauncher.

private async void ShareBtn_Click(object sender, RoutedEventArgs e)
    await file.CopyAsync(ApplicationData.Current.LocalFolder);
    await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();

To use the FullTrustProcessLauncher we will use the Desktop extension to UWP, this extension is available as an SDK reference available in the Add References dialog of the UWP application:

And finally, register the desktop extension and the target executable in the manifest:

<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" 
         IgnorableNamespaces="uap mp rescap desktop">
<... >
<desktop:Extension Category="windows.fullTrustProcess"                   
                   Executable="WPFPhotoViewerWPFPhotoViewer.exe" />
<... >

3. Enable Office interop from UWP application

One of the key features of the Desktop Bridge is the ability to include Win32 executables on your application package and run those as full trust process from a UWP application. Now, with the Windows Application Packaging project, you can create packages that contain both UWP and Win32 binaries.

Additionally, to the process launcher, the App Service extension will help you to establish a communication channel between your UWP application and the Win32 process.

In this sample we are going to include a Win32 process (a command line application) to manage an Excel worksheet using office interop.

We start with a UWP application that uses the Telerik data grid to show some tabular data, and we will add button to export the same data to Excel as shown in the image below:

The solution explorer of this example looks very similar to our previous example, with three projects in the solution: The UWP application, the Win32 command line and the packaging project with a reference to both projects. However, note that in this case the Application entry point (shown in bold) is the UWP project:

As we did in our previous example, we need to add a reference to the Desktop extension and register the full trust process in the manifest. But this time, we will also register the application service in the package manifest:

To open the communication channel in the Win32 process, we will add a reference to the Windows API as described here:

To establish the connection, we will use the AppServiceConnection class, where we need to specify the package family name of the application we want to connect with, and the event handlers we will use to process the incoming requests.

Connection = new AppServiceConnection();
connection.AppServiceName = "ExcelInteropService";
connection.PackageFamilyName = Windows.ApplicationModel.Package.Current.Id.FamilyName;
connection.RequestReceived += Connection_RequestReceived;
connection.ServiceClosed += Connection_ServiceClosed;


The new features added to the packaging project in Visual Studio 2017 will help you to modernize your existing desktop applications to get the best from UWP and Win32 in the same package. This new project will help you to configure your package by using the manifest designer, debug your application in the context of the Desktop Bridge and finally, help to create the packages for store submission or sideloading. Here are some resources for more details:

Are you ready to submit your desktop application to the Microsoft Store? Let us know about it here, and we will help you through the process!

Go to Source

Share this
04 Dec 2017

Breaking on DOM Mutations in the Microsoft Edge DevTools

Author: Brendyn Alexander
Go to Source

Editor’s note: This continues the series we began last week, highlighting what’s new and improved in the Microsoft Edge DevTools with EdgeHTML 16.

As the web platform evolves, the line between web and application developers continues to blur. It’s common now for a web site to be more like a web app, with complex, single-page user interfaces built up by a combination of libraries and custom JavaScript code. This in turn has led to a web platform that requires more sophisticated tools to efficiently debug.

As we rely more and more on JavaScript to build up the DOM, and rely on tools that interact with and abstract away from us the nuances of DOMs across browsers, we lose the ability to easily know what caused a change to an interface node, especially if that change is unexpected. In EdgeHTML 16 (available with the Windows 10 Fall Creators Update), we’ve introduced the ability to break on mutations caused by any of the 450+ DOM APIs in the EdgeHTML platform and jump directly to the script that triggered the change.

For those who use Chrome DevTools, this will be a familiar and welcome addition to Edge debugging. It was our goal to implement and advance on a similar experience to make jumping between the two tools as seamless as possible. Read on for the changes you can expect in the Fall Creators Update (and can preview now via Windows Insider builds).

Breakpoint types

There are three breakpoint types:

  • Subtree modifications: when a node is added or removed from the subtree of the element on which the breakpoint is set
  • Node removal: when the node the breakpoint is set on is removed from the DOM tree
  • Attribute modifications: when an attribute of the node on which the breakpoint is set is modified

Setting and managing breakpoints

To set a breakpoint, right-click on a node in the DOM tree in the Elements tool. Under the DOM breakpoints item, you’ll see options to set and unset the supported breakpoint types.

Screen capture showing the context menu option to add DOM breakpoints in the Elements tool.

Add new breakpoints by right-clicking a node in the DOM tree and selecting “DOM breakpoints.”

When you add a breakpoint, a red breakpoint indicator appears next to the node in the DOM tree. The breakpoint is also listed in the DOM breakpoints pane which exists in both the Elements and Debugger tools. You can disable and delete breakpoints by using the mouse to click the checkbox and delete icons, respectively. You can also right-click, or use the keyboard, on a breakpoint to invoke a context menu to apply the same actions:

Screen capture showing the right-click options on breakpoints in the DOM Breakpoints pane.

Disable or delete breakpoints in the new DOM Breakpoints pane.

Triggering a breakpoint

A breakpoint is triggered whenever one of over 450+ DOM APIs are called by JavaScript. When the breakpoint triggers, you’ll jump to the Debugger tool with the file containing the triggering script opened and the line with the API call highlighted.

Screen capture showing a DOM breakpoint triggered on a page and the associated API call highlighted in the Debugger tool.

When a DOM API triggers a breakpoint, the Debugger tool will open with the API call highlighted.

In the Debugger tab, you’ll notice at the top of the call stack is an entry with the selector for the node the breakpoint was triggered on, and the type of breakpoint triggered.

Screen capture showing the Debugger tab open with the selector for the node the breakpoint was triggered on, and type of breakpoint triggered.

Breakpoint persistence

We store breakpoints as part of your Edge DevTools settings and scope them to the URL of the page they’re set within. When you close and re-open Edge DevTools, or refresh the page, we’ll restore and attempt to automatically rebind the breakpoints to their respective DOM nodes. If we’re unable to automatically rebind them, we’ll indicate that they’re unbound in the UI with a warning icon on the breakpoint circle.

Screen capture showing DOM Brekapoints pane with warning icons for unbound breakpoints.

Breakpoints that cannot be rebound when the session is restored will show an alert icon in the Breakpoints pane.

You can use the context menus or shortcut icons in the DOM breakpoints panes to manually rebind any breakpoints we were unable to automatically rebind.

What’s next for DOM Breakpoints

We’re excited to launch this feature and hope to solve for as many developer scenarios as we can, but want to highlight a few gaps in the current implementation:

  • We don’t currently support rebinding breakpoints inside iframes. If you set a breakpoint in an iframe and close Edge DevTools or refresh the page, the breakpoint will be lost.
  • If your script encounters a synchronously-executed breakpoint before the DOM readyState is completed, you won’t be able to set a DOM breakpoint while the debugger is paused. You can typically remedy this situation by setting the defer or async script attributes.
  • For synchronous scripts, we trigger automatic rebinding of breakpoints when the window.onload event is called. In this case, we may miss binding breakpoints that would trigger during initial script-driven build-up of the DOM. For asynchronous scripts, we trigger a rebind attempt before the first script executes, so your breakpoints may rebind and trigger as desired.

We’re evaluating closing these gaps in future releases, as we continue to evaluate the prevalence of these scenarios. If you have feedback and find these unsupported areas to be blockers, please let us know!

Tell us what you think

We hope you enjoy this new addition and find it improves your productivity as you go about your developer workflows. If you find any bugs, please report them via the Feedback Hub. If you have questions or feature requests, don’t hesitate to leave a comment here, or reach out to us on UserVoice or Twitter.

­Brendyn Alexander, Senior Program Manager, Microsoft Edge DevTools

Go to Source

Share this
04 Dec 2017
04 Dec 2017
04 Dec 2017
04 Dec 2017
04 Dec 2017

© 2010-2018 Alt-Tech Inc. All rights reserved.

Click Me