Archives
-
The evil of the Office UI ribbon license
For the next major version of a certain application I'm working on (gee, what might that be
) I'm researching some UI frameworks and techniques. In the past few months I've spend most of my time working on application support library code, language designs, algorithm design etc. etc. (more on that in a later article) and I arrived at the point where I wanted to see how my vision for the major version would work in a draft application, just to see how the various elements would work together visually.
One of the first questions one would ask these days when a new desktop application is started is: WPF or Winforms? The current version is build with Winforms all the way though it's tempting to go for WPF, as it's new, has nice performance and great looks (if you're able to cook up the styles). After a day or 2 of fiddling with the various WPF docking frameworks out there, there's one firm conclusion to be drawn: WPF isn't up to par with Winforms when it comes to serious applications which use a normal windows look and feel: automatic menu, buttonbar handling based on selected docked window for example, one of the cool features of many winforms control libraries, is one of those things which is hard to do in WPF (at least, it's not directly available/build in). One other thing which made me draw the above conclusion was that it in general sucks bigtime when you have a normal windows application with normal menus: the text is in general blurry (or at least blurry in a short period of time after a move/open) and to make the menus to look like normal menus like in VS.NET is a pain (it doesn't get close).
Because we will need a custom rendering system in this major version for some areas, we do need WPF. However, one can host a WPF control just fine in a winforms application, so re-using our already written winforms skeleton was a choice I didn't expect at first but which makes sense. -
Linq to LLBLGen Pro: feature highlights, part 2
In the first part of this series I talked about the fact that Linq to LLBLGen Pro is a full implementation of Linq and why it's so important to use a full linq provider instead of a half-baked one. Today, I'll discuss a couple of native LLBLGen Pro features we've added to our Linq provider via extension methods: hierarchical fetches and exclusion of entity fields in a query. Furthermore some other features will be in the spotlight as well. What I also want to highlight is that using an O/R mapper is more than just filling dumb classes with dumb data: it's entity management, and the O/R mapper framework should offer you tools so you will be able to manage and do whatever you want with the entity graph in memory with as less problems and friction as possible. After all, the task you have isn't writing infrastructure code, entity classes nor code to make these interact with eachother, your task is to write code which consumes these classes, and works with these classes. This thus means that you should be able to work on that code from the get-go, as that's what your client expects from you
.
-
Software Development Meme
Shawn Wildermuth passed the torch to me (among others) in a new version of an old blog-theme. Oh well, these are always fun
. It's more or less an interview-like way of pulling trivia out of people, so here we go!