The UWP Notepad Project (Redux): File Open and Custom Dialogs (Premium)

If you followed along with my series The UWP Files, you will recall that me coming to grips with asynchronous programming was a major stumbling block that required weeks of research and work on my part before I finally figured it out. But there was another problem, too. As it turns out, some of the issues I had experienced were related to the invisible firing of event handlers that I briefly mentioned in the previous installment in this series.

Well, I’d like to put all that behind me now. But before we can move forward, we need to briefly discuss asynchronous programming and how it’s used in the Universal Windows Platform (UWP). In previous frameworks---Windows Forms and the Windows Presentation Foundation (WPF)---the code we wrote always ran synchronously, which is to say in order from beginning to end. Consider the following pseudocode:
line of code;
doSomething();
another line of code;
When the doSomething() method is called, the next line of code (“another line of code”) won’t run until doSomething() completes executing.

But in asynchronous programming, it’s possible to run methods asynchronously. This means that that “another line of code” can execute before doSomething() completes executing. In interactive and graphical applications, this is desirable at times when synchronous code execution can cause the application to appear to hang or stall because it has to wait on some time-consuming operation to complete.

For our purposes, asynchronous programming is being forced on us: In UWP, the APIs for file operations and dialogs are implemented asynchronously. So we have to do things a bit differently.

For example, consider the following made-up code in which we have a method called DisplayMessageBox() that, well, displays a message box (which has been renamed to message dialog in UWP). If UWP allowed us to do this synchronously, like we would have in WinForms or WPF, that code might look like so:
private void DisplayMessageBox
{
MessageDialog messageDialog = new MessageDialog("Hello!");
messageDialog.Show();
}
But that’s not how UWP does things. Instead, this method in UWP would look something like this:
private async Task DisplayMessageBox
{
MessageDialog messageDialog = new MessageDialog("Hello!");
await messageDialog.ShowAsync();
}
There are several differences.

First, while you can return void on an asynchronous method, you should never do that unless you’re in an event handler (as with a button click or whatever). So we return a Task instead. This can be treated like void if you don’t need to do anything with it, but if the method does need to return a value, you can do so in the form of Task<T>---like Task<int> (or whatever)---and use the return keyword in the method to output the value need (int in this case).

Second, the async keyword indicates that we’re going to do something asynchronously inside the method. (That something is the ShowAsync metho...

Gain unlimited access to Premium articles.

With technology shaping our everyday lives, how could we not dig deeper?

Thurrott Premium delivers an honest and thorough perspective about the technologies we use and rely on everyday. Discover deeper content as a Premium member.

Tagged with

Share post

Please check our Community Guidelines before commenting

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC