Posts

Something very much like a PropertyGrid!

I've been working on a WPF Toolkit for my pastime project CrystalWars tonight, when I stumbled upon this lovely implementation of a PropertyGrid in WPF . At first sight, and working with basic data types only, it works very smoothly. I'll have to dive into the custom section in the next few days nights. The tutorial looks pretty telling to me.

Getting the Crisp back into your WPF Apps

Bild
WPF has a lot of advantages, it's perfectly sane data binding mechanism being one of the most outstanding ones.On the flipside, many people (meaning companies, mostly) have refused to switch from WinForms to WPF because of the "blurry" looks of applications written in WPF. This blurryness goes back to two mechanisms: 1)Text Smoothing Instead of relying on the system's ClearType mechanism, WPF does it's own thing-a-magic, which is blatantly inferior to the aforesaid. In fact, WPF smoothed fonts are a definite way to headaches, if read for some time. Note : The image is from a website that compares various Microsoft.Net Font-Smoothing implementations. They might be useful to integrate text in images, though.For business applications (displaying data grids etc.) this is a K.O. criterion. Nobody wants to have to take their glasses off in order to achieve readability, and nobody wants their software deployed along with a pack of aspirins. 2)SubPix...

Deploying ClickOnce-applications in different environments without modifying the assembly identity

Bild
The following describes a method that is viable for ClickOnce deployment using "Online Only" mode. One of the aspects I recently pondered about is code identity. In other words : Auditors ask me how I ensure that the software tested and accepted by the departments is exactly and with no alternations the assembly we deploy for productive use and not some tinkered-with version. "That's easy", I say, "I can't!". Because some config-variables are set between approval and release, the ClickOnce hashes differ and thus does the whole thing. The image depicts the requirement rather roughly, but I think more detail is not required: An application should be stateless and not compiled to fit it's environment. The first thing coming to my mind to sail around this kind of trouble is keeping the App.config (or any other file of my personal gusto) a part of the deployment, but removing it from the hash. That would be easy, fast and a little dirty. First and f...

Duplicate items are not supported by the "Resources" parameter

This is an Error Message that I have encountered for the first time today. It is most likely to occur when you copy forms and rename the copy automatically, which will cause the original to be renamed, too. In my first project I split the code of a Form into many partial classes, one partial class for each tab in the form. I created new partial classes the copy & paste way, which worked alright before, but today I got the Message The item [...].resources was specified more than once in the "Resources" parameter. Duplicate items are not supported by the "Resources" parameter Actually you can only have one Resources File per class. What I did was unknowingly copy the form including the resources file (...that the VS project explorer hides under the Form's node), so that the resources were double-linked. Solution: delete the second resource file. BTW: As of now, I will also try to make my posts googleable for developers with a german IDE by adding German se...

Pulling the rug from under Uncle FileSystemWatcher

The FileSystemWatcher class is a nice treat if you need to trace file system modifications (e.g. wait for a file to be created or deleted in a specific path). The full MSDN documentation gives specs and usage examples. You will see it's easy to use and still powerful, allowing a variety of scenarios to be monitored. There is one point, though, that I had to painfully find out by messing it up before realizing it was an issue at all. Imagine the following scenario: - You are monitoring a network path (UNC or mapped drive), or let's rather say your FileSystemWatcher is. - The network path becomes unavailable (deleted or unavailable due to network trouble...) What would you expect? Well, forget about that, because what actually happens is the following: Nothing. Period.Even if the path resurfaces, your FileSystemWatcher is out of its game. That renders it rather useless, because who has a use for a deaf event listener? Anyway, that's what recently happened within a windows s...

Using AutoMapper for MVVM implementations

Being Clean Code Developers, whenever we start developing a new application, we try to improve our code quality, right? As a part of that, we librarify what can be librarified and use 3rd Party and Open Source assemblies wherever possible so we can concentrate on the really dirty work. OK, here's one thing Stefan Lieser brought to my attention in the course a Google Group discussion. It's called AutoMapper , and as the name gives away is a great deal of help when you have to map instances of Type A to instances of type B (very simply put, really). Sounds rather boring at first glance, but me and my buddy Maik decided we'd take a look at it for our nhibernate based MVVM implementations, in which (up to now) the viewmodels were wrappers / proxies for the models. Apart from that, it does great Conversions from one list type to another, which was a numb piece of loop-through-source-store-in-destination. The Gloria : Stickiness of memory addresses Having worked with NHibernate,...

A Retrospective look at the PRIO09 Conference

Bild
This year’s PRIO took place in Munich and was entitled with the rather general term “UI”, which seemed more than convenient for me, being a UI Developer ever since I wrote my first homepage back in 1997. Taking a look at the program for day one , I knew right away that I wouldn’t get far by following one of the predefined tracks. On the other side, it contained a whole Silverlight track, which I have no use for and could thus discard without further consideration (Same goes for the partner sessions). As a result I hopped between practical and conceptual talks, with a result that was way above my expectations. To mention the day’s hightlights : Mr. Urs Enzler shed some light on how he and his folks implement the single responsibility paradigm in combination with established patterns like M-V-VM, a both informative and important issue. After that I went (or rather stayed) to see and hear Bernd Marquardt, who brilliantly explained what’s currently in stock for writing Multi-threaded UIs...