My new talk about .NET Threading that I held last Monday at the .NET User Group Regensburg is now online. In it, we’ll take a look behind the curtain of threads, the thread pool, tasks and async await as well as lock-free programming.
My previous two posts about Bertrand Meyer’s Design by Contract (DbC) were mainly introductions to pre- and post-conditions and class invariants and how they can be implemented in C# – in this one we’ll check out what implications DbC has if it is combined with the inheritance mechanism of object-oriented programming languages.
If you happen to speak German, you can watch the video of my latest talk at the .NET User Group Regensburg which I held on last Monday, the 25th. of January. In it, we discuss the basics of Design by Contract with its Pre- and Post-Condtions, Class Invariants, and Variants and Invariants for loops as well as a framework called Code Contracts that provides functionality to introduce DbC in .NET. Furthermore, we check out alternatives to Code Contracts and the importance of executable specifications.
If you’ve ever programmed in XAML-based technologies, you for sure know Resource Dictionaries: these XAML files usually contain the styles and templates you want to share across different views, or provide the default styles for Custom Controls you’ve written.
If you want to merge Resource Dictionaries into others (like e.g. within your App.xaml file), you normally use so-called PACK URIs to reference them. However, there is another way: you can combine your XAML file with a code-behind file to create a subclass of ResourceDictionary and reference it via its class name. This is what I call Stronger-Typed Resource Dictionaries.
In my last post, we discussed the problem that text controls residing in a FlipView are not scrolled / moved to the top area when the Windows touch keyboard fades in at the bottom area of the screen. In this post, we take a look at the keyboard dismiss problem that also occurs when you put input controls into a FlipView.
In the Universal Windows Platform, you can use a control called FlipView to present a collection of items to the user. These items are shown one at a time and the user can perform swipe gestures (a.k.a flips) to navigate to the next or previous one in the sequence. While the FlipView is generally designed to display content that can only be viewed by the user (like e.g. an image gallery), I decided to use it as part of a forms layout where logically related input controls are put on the same page, and when the user is finished with them, he or she can swipe to the next page to fill out its form items. However, there are some issues with this approach when the user is using the touch keyboard that comes with Windows.
Are you writing Windows 10 Apps already? I’m currently updating one app from Windows 8.1 Store to the Universal Windows Platform, which of course means that some redesign is required, too. If you ever have developed a Windows Store App, you probably know the Segoe UI Symbol font because it offers a lot of icons that you can use for e.g. buttons in the app bar. The benefit is clear…
Recently, one of my former students contacted me about a problem he had with the WPF Combo Box. He wanted to display a hint that a wrong value is currently selected. I thought this is an easy answer because WPF supports Error Templates that can be used to display additional UI Elements on the WPF Adorner Layer. But of course, the answer was not that easy.
In one of my last posts, I discussed the basics of Bertrand Meyer’s Design by Contract, namely pre- and post-conditions on methods. These Boolean assertions are used to check if the caller supplied valid arguments and performed the call while the target object was in a valid state, as well as to verify that the method produced the correct return value and/or side effects after it executed completely. This allows us to give semantical meaning to methods on our objects.
In one of his recent posts, Mark Seemann argued that you should not use the internal modifier for types and their members, because this decreases the testability of your code. While I totally agree with him on the subject, I want to highlight another reason for not using internal: the extensibility of your reusable code bases.