My current project presented a unique challenge. I have a need to:
- allow only one instance of the application to run at each workstation,
- notify the user that an instance is already running if a second instance is started, and
- be able to programmatically restart the application.
Thankfully, Microsoft has provided the SingleInstance.cs to serve these needs. Following this article on CodeProject.com was a great start. The author Arik Poznanski did an excellent job explaining the steps necessary to implement the first two requirements. I combined his techniques with information found in this article on StackOverflow.com to fully satisfy all three requirements – an application that will only allow one instance, that will notify the user that an instance is already running, and that can easily be restarted programmatically. Continue reading
When I wrote my article regarding use of the BackgroundWorker to keep the UI responsive, I used the WebClient’s DownloadString method as an example of a long-running process. I used this as an example in explaining how to use the BackgroundWorker, which simply allows for thread-blocking code to be run in a separate thread.
As it turns out, this is a terrible idea. Not the whole thread-blocking code in a separate thread, but the use of a WebClient in a BackgroundWorker. You see, the WebClient class implements a DownloadStringAsync() method. This allows the calling code to continue to run, and the asynchronous process will eventually return a string. But since it’s asynchronous, our UI thread will never get blocked by a long-running process. And since it too supports asynchronous cancellation, there’s no reason to embed it inside a BackgroundWorker. Continue reading
As I mentioned in my article on implementing the BackgroundWorker to keep your WPF user interface responsive, the BackgroundWorker class supports cancellation. I will illustrate here how easy it is to accomplish.
I’ll build this example by continuing the example in the previous article. First, let’s add a BackgroundWorker property to our DataModel class. Continue reading
I was in search of an easy implementation of a splash screen for my current project. I wanted to be able to show a splash screen and update it with current status information as my application initialized.
The standard SplashScreen class provided by Microsoft does not support showing dynamic content on the SplashScreen. For this reason, I was not able to use the supplied class. Instead I decided to create my own.
The splash screen I created is simply a regular window bound to a view model. I’ve created a SplashScreenHelper static class that we’ll use to send status updates to the splash screen. Continue reading
I’m currently working with Linq-to-SQL, and have used attribute mapping to map my classes to database tables. In doing so, I’ve created a
Database context that derives from DataContext (and takes my encrypted connection string stored in settings as a default parameter). To create a database connection, I simply use typical code as illustrated below.
Note that the following terms are referred to below, but not included for brevity:
ViewModelBase – provides
Customer – a typical class representing a Customer object
In my current project, we had a need to create a custom WPF dialog box. Writing our own provides us the ability to easily skin the window with our application’s theme as well as gives us the ability to generate any buttons we wanted.
We wanted our custom dialog box to be able to:
- Display a message to the user
- Provide various button options (OK, OK/Cancel, Yes/No, Yes/No/Cancel, etc)
- Return the button clicked by the user
- Display an optional CheckBox
- Display text next to the optional CheckBox
- Accept a boolean property for the default IsChecked state of the optional CheckBox
- Provide the IsChecked value of the optional CheckBox as an out parameter
The other day I started moving all my event handlers in my application from the View’s code-behind file to the ViewModel. I accomplished this using command binding. This was all easy enough – until I came to my Close method.
You see, in the MVVM (Model – View – View Model) design pattern, the ViewModel – a class that typically contains the values you want to display in your View – shouldn’t know anything about the View. It’s OK (and quite necessary!) for the View to be aware of the ViewModel, however.
So let’s take a look at the Close button’s event handler as it originally existed in code-behind:
private void Close_Click(object sender, RoutedEventArgs e)