Raising an INotifyPropertyChanged event requires a string containing the affected property’s name. Developers want a simple, clean and performance-efficient way to populate this string. New versions of .Net have brought developers closer and closer to achieving this goal.
Let’s review how INotifyPropertyChanged implementation options have improved over the years. Then, let’s consider an idea on how these options might be made even better. Continue reading
With the recent release of .Net 4.5/C# 5, I’ve spent time experimenting with the new async/await functionality. To my surprise, these new keywords didn’t have the effect I anticipated. Based on my skimming of pre-release information, I was under the impression that the appropriate use of these keywords would cause a normally-synchronous method to execute asynchronously.
Wrong! Continue reading
Segmenting unit tests from release code by placing the tests in a separate assembly (e.g. in a separate Microsoft Visual Studio project) is a good idea. However, making release code classes public in order to allow the unit test assembly to access them isn’t a good practice. Continue reading
Imagine a master-detail form. The top portion of the window contains a grid listing people’s names. Below is a form where the currently-selected person’s details may be edited. Should data-binding be used to connect the edit form’s fields directly to the grid’s currently selected record (row)? To put it another way, should the grid’s selected item and the edit form both be referencing the same in-memory object instance? Continue reading
Today, while doing some research in the MSDN Library, I came across an interesting use of C#’s goto statement. Instead of causing the application’s execution to jump to a named label—a practice frowned upon in the programming world—this example used goto to emulate C/C++’s switch statement’s fall through behavior. Continue reading
C#’s null-coalescing operator (??) simplifies the syntax required to say “the value of an expression is x unless x is null in which case the value is y.”
Suppose we want to set the variable salary to a value fetched from the database. However, if the database returns null, salary should be set to 0. Continue reading
A hidden source code file is auto-generated for each WPF XAML file. The names used for this file and for the class it contains are based off the XAML file’s filename. In a C# application, the file MyWindow.xaml will have a hidden code-behind file named MyWindow.g.cs containing a class named MyWindow.
The contained class inherits from the WPF core class corresponding to the associated XAML file’s root element. If the root element in the XAML file is <Window>, the class in the hidden code-behind file will inherit from Window.
A ListView’s data display needs to be updated. The revised dataset, retrieved from the service layer, is contained in a new collection containing new object instances. Setting this IList<T> as the control’s new ItemsSource causes the control to display the revised data and…whoa…clears the currently selected item.
From the technical perspective, this clearing makes sense. A new collection has been displayed making the selected item from the previous collection irrelevant. However, from the user’s perspective, the same collection is displayed both before and after the refresh (albeit with revised data), so the current item selection is still pertinent and should be maintained.
The typical WPF application—as viewed in Solution Explorer—consists primarily of XAML files (.xaml) paired with code-behind files (.xaml.cs) and ordinary source code files (.cs). None of these files contains a static Main() method—the starting point of execution in a C# program. Where then does execution begin in a C#.Net WPF application?
Crash! The offending XAML sets a control’s style property to a StaticResource (e.g. <Button Style=”{StaticResource myStyle}” />). The named style is defined in <Application.Resources>. Why then the XamlParseException “Cannot find resource…” exception?