Execution starts when the button is clicked and button1_Click event is fired on the UI thread.

2

The method, named LongRunningProcess, is invoked.

3

The lamda expression passed to Task.Run() executes in a separate thread (lets call it thread_B)

4

Now await keyword is encountered, rather than completing the rest of the method, control returns back to button1_Click event to continue execution after the call to long running method.

5

Calling task1.Result makes the current thread wait on thread_B to complete and provide the results. So UI thread is now waiting for thread_B to complete.

6

As thread_B completes the task, it has to run the remaining part of long running method. Run time ensures that this code executes on the right context. That is, if the initial part of long running method was executed on the UI thread, then remaining part will also be executed in the same thread context.

7

Therefore, thread_B now attempts to run the remaining part of long running method on UI thread, while UI thread is waiting for thread_B to finish.

8

As UI thread and thread_B are waiting for each other, this creates the deadlock.

How to avoid deadlock?

In this case, deadlock can be avoided by anyone of the following ways:

Why thread contexts are synchronized?

Consider the UI Controls (Windows Forms or WPF), they are not thread safe. Therefore, any update to the UI controls must be done only from the UI thread. To take care of this, any remaining code after await keyword in an asynchronous method will also execute on the thread context which initiated the method call.

Similarly, in an ASP.Net application, running the code on same thread context is important because the Culture, Principal and other information of the request are stored in the thread.

How thread contexts are synchronized?

To manage all this tricky context synchronization, we have SynchronizationContext class in .Net. There are framework specific implementations (derived classes) for Windows Forms, WPF/Silverlight and ASP.Net which handle the SynchronizationContext in their own ways for the framework to function properly.

The Windows Forms implementation uses Control.Invoke method to accomplish this (more details here). For ASP.NET, execution takes place on a different thread but the context is captured and passed on to the new thread.

The code we want to run asynchronously could either be CPU-bound or IO-bound. CPU-bound code keeps the CPU busy, requiring intensive processing, calculations etc. On the other hand, IO-bound code frees up the CPU while waiting for an IO operation to complete, for instance, get some data from a web service. Both kinds of asynchronous methods are illustrated below.

Creating Asynchronous method

CPU-bound Async method

Above method doesn’t do anything special. Rather than performing the work itself, it creates a thread and delegates the work to it. It will not make the task run faster, in fact, it may take more time due to multi-threading overhead. One reason to do things this way is to free the calling thread and not keep it busy for long time. This is required in case of User Interface threads, for instance.

IO-Bound Async method

For IO operation such as working with file system, requests to web servers etc., .Net framework already provides us with methods which run asynchronously. These methods uses lower levels OS calls to provide asynchronous behavior for blocking IO operations.

Consuming asynchronous method

Consuming asynchronous method with await

This button click event consumes the IO-bound async method defined above. If GetWebPage method is taking a long time, the control will return back to the caller method. Once results of GetWebPage are available, execution will start again with the instruction after await keyword. This will ensure that the event does not block the UI thread.

Notice we are not using await keyword now when invoking GetWebPage method. This causes the return type to change also, we are expecting Task<string> rather than string object.

The flow control is also very different. If GetWebPage is blocking, the control doesn’t return to the caller method, rather execution continues to the next statement in the event.

We have await in the third line which will relinquish control to the caller method if task1 or task2 are not completed yet. When the result of the two tasks are available the last two lines of code are executed on the UI thread.

The User Interface (UI) becomes unresponsive when a time taking operation is executed during an event.

Consider the following button click event where I have simulated a time taking operation by calling Sleep method. In a real scenario, it could be some processing which produces the result to be shown back on the user interface.

Keeping UI responsive through System.Threading.Tasks.Task

To keep the UI responsive, we can spawn a new thread to perform the time taking operation. Earlier, we used to do it with System.Threading.Thread but now we have more convenient Task class from TPL (Task Parallel Library) in .Net.

If we run the above code in debug mode, we get the following exception:

UI controls are not thread-safe, therefore, call to the UI should only be made from UI thread which created these controls.

The way around this problem is to use Invoke method of the control and pass it a delegate which performs the required UI changes. Invoke method will ensure that the delegate is executed on the UI thread.

With async / await, the code looks more synchronous and readable. As await keyword is encountered, a new thread is started for processing the task and the method returns the control back to the caller (this ensures that the UI thread is free and responsive). Once the task is completed, rest of the code for the click event is executed on the UI thread. Behind the scene, compiler generates complex state machine logic to make this happen seamlessly.

There are some tools which convert C# code to JavaScript. Obviously these will only be useful if your code is not tightly coupled with any C# library as the library won’t be available in JavaScript. These conversion tools may come handy for model classes or any other logic which is, for the most part, independent of .Net framework classes.

The main focus of these tools is not code conversion, rather they primarily try to do for C# what GWT does for Java. They allow you to write code in C#, access the DOM and JavaScript libraries to develop web applications. When the code is compiled, the output is not .Net Application but a web application written in JavaScript and HTML.

SharpKit is commercial (free for open source & small projects) as opposed to the alternatives listed below but does an excellent job of converting C# to JavaScript which is clean and readable. Moreover, it supports all features of C# language.You can see SharpKit live in action here. Give it a C# class or a snippet, it will convert it to JavaScript right there.

JSIL is a compiler that transforms .NET applications and libraries from their native executable format (CIL bytecode) into standards-compliant, cross-browser JavaScript.There are quite a few demos on JSIL website, one of them allows you to convert C# code to JavaScript right in the browser (though the generated code looks a bit obscure).

Script# is a compiler that generate the JavaScript instead of MSIL (Microsoft Intermediate Language) from C# source code like GWT (Google Web Toolkit).Script# supports a subset of language features, for instance enum and struct are not supported.

Developed a Custom FontDialog as an alternative to the standard .Net FontDialog. Key advantage of CustomFontDialog is the full control over look and feel as it is open source. Source and binary files are available at sourceforge.

CustomFontDialog avoids ‘This is not a True Type Font’ exception that affects the standard dialog in some cases. Most probably the exception happens when some installed fonts have invalid meta information. This exception cannot be caught using try/catch block because the exception is thrown from the code outside .Net framework. The exact exception message is ‘Only TrueType fonts are supported. This is not a TrueType font.’. CustomFontDialog gets around this problem by loading only True Type fonts. More details about the problem with standard dialog can be found here and here.

Moreover, CustomFontDialog provides easy access to recently used fonts by moving them at the top of the list in ‘Recently Used’ section.

Usage

Following C# code snippet demonstrates how to instantiate and display Custom FontDialog.

For the CustomFontDialog to retain the recently selected fonts at the top of the list, the dialog should be instantiated only once and ShowDialog function should be called on the same object whenever the dialog needs to be displayed.

To programmatically add Fonts to be ‘Recently Used Fonts’ section, call AddFontToRecentList method.

Limitation: As compared to the standard FontDialog, CustomFontDialog doesn’t support changing text color.

Updates

Version 0.2.0 (31-May-2014)

Following fixes and enhancements are included in this version:

1- In Font List, arrow keys can be used to move between ‘Recently Used’ and ‘All Fonts’ sections.
2- When user starts typing in Font List, the focus shifts to the filter Text box automatically.
3- Whenever CustomFontDialog is displayed, the focus is on Font List by default.

Switch cases list all desired characters which will be displayed, rest of the characters are ignored. If additional characters are required, they may be included as switch cases. For instance, negative sign may be allowed based on your requirement.

It seems that .Net library doesn’t provide any way to scroll contents of ListBox through code. Selecting an item by setting SelectedIndex automatically scrolls the list to bring the item into view but this may not produce the desired effect. In my case, I wanted to programmatically select an item and make it the first visible item in the list. This effect cannot be achieved through changing SelectedIndex.

The way around this problem is to invoke Windows API SendMessage function.

To call a function from an un-managed DLL, we have to declare it along with DLLImport attribute.

This is the handle to ListBox Control. We can get the handle through Handle property of ListBox control e.g. myListBox.Handle

2

uint Msg

This should be set as WM_VSCROLL. It says that we want to send message for scrolling vertically. Find list of messages that could be passed to a control here.

3

uint wParam

This 32 bit parameter has two parts.

Lower 16 bits called LOWORD should specify one of the scroll bar commands. In our case, it should be SB_THUMBPOSITION.

Higher 16 bits called HIWORD should specify the numerical value for position of the scroll bar thumb. If we pass the index of a list item, list will scroll such that the item becomes the first visible item in the list.

4

uint lParam

This parameter is for additional message specific information. For our purposes, we will just pass 0.

Following is the SendMessage function call to scroll the list. First, we define the constants WM_VSCROLL and SB_THUMBPOSITION. Then we develop the thrid paramter by combining LOWORD and HIWORD. Finally the function is called.

I came across a situation where I needed a collection which can hold recently used objects of a particular kind. For instance, recently opened files, recently used fonts or colors etc. Such a list should demonstrate following behavior:

List should have a limited size (or call it maximum size). As list grows beyond the maximum size, the oldest item should be dropped.

Newly added items should be inserted at the top of the list i.e. index 0.

If an item to be added already exists in the list, it should be moved to the top of the list (at index 0) rather than being duplicated. This means that entries in the list will always be unique and order of the items will follow how recently they were used.

But these events does not fire when arrow keys are pressed. One way to get around it is to set KeyPreview as true for your Form. In many cases, this also doesn’t work, for instance, when you have buttons on your Form.

In such cases, ProcessCmdKey can be overridden to detect and handle arrow key events.

After handling the arrow key event if you do not want the standard arrow key functionality to kick in, return true rather than calling return base.ProcessCmdKey(ref msg, keyData); Standard functionality could be to move focus to the next or previous control.

Returning true from ProcessCmdKey means event has been handled and should not be routed further for processing.