I just released version 2.0 of Light.GuardClauses. This version brings new features and some breaking changes. Let’s check them out!
Everything on Tag: C#
Last year in May, I published Light.GuardClauses, a .NET Portable Class Library that lets you perform easy precondition checks at the beginning of your methods. Last Wednesday, I released v1.3 which brings the following new features to you…
My .NET Threading in Detail talk that I gave at the .NET Developer Group Ulm last Wednesday is now online. If you happen to speak German, you can watch it on my YouTube Channel.
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.
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.
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.
During the past weeks, I have been releasing videos on the Dependency Inversion Principle (DIP) which was originally published by Uncle Bob in 1996. I’m happy to announce that my video series is finished – you can watch it on YouTube now.