I was recently asked by Omar Besiso, what I would do to mitigate the performance issues faced when your WPF application leverages gradient’s in a variety of areas of the application, while the application is used remotely. I kept thinking, but couldn’t really come up with an answer straight up. I was told that the answer was to not use gradient’s at all. At first I did accept that as a plausible answer, considering Microsoft Expression Suite also seem to have solid colours for their entire UI. However being a developer who highly considers eye candy as being important, I decided to set out to look for a better solution to this problem.
I haven’t really dived deep into the new bits with WPF 4 since installing VS2010 Beta 2, I decided to blog about the new Windows 7 taskbar-integration features that comes supported with WPF 4.
Although Microsoft released a Windows 7 Code Pack, allowing you to leverage the great new taskbar features in Windows 7, as well as many of the new Windows 7 features. There wasn’t really an easy way to do this through XAML. I’m quite happy to see this now in WPF4, and how easy it is to enable these taskbar goodies for your WPF applications. I’m going to just start off with talking about two apparent features that I’m sure most developers would like to bring to their applications: Taskbar Progress and Taskbar Overlays.
For the early and recent adopters, you may have noticed that the taskbar buttons are now more richer in terms of the feedback that’s shown to users. One of those is progress updates. This is particularly useful when you have a long running operation, like a copy/move operation, where you would usually minimize the window to (at least, that’s what I do), and you also want to quickly see how it’s doing.
This is what an explorer copy and paste operation looks like:
It’s really useful to see the progress of a long running operation without having to restore or bring it back into focus.
In order to enable your applications to report progress to the taskbar, you will be required to add this feature into your applications.
Fortunately, WPF 4 now introduces a generic taskbar item class(TaskbarItemInfo) that allows you to configure this. If you want to configure your application to have an indeterminate progress, you simply have to set the TaskbarItemInfo.ProgressState to Indeterminate.
<Window.TaskbarItemInfo> <TaskbarItemInfo ProgressState="Indeterminate" /> </Window.TaskbarItemInfo>
And this is what it ends up looking like:
If your application can determine the remaining progress, you can choose to set the ProgressState to Normal, and then within your code, whether it be through the code behind, a command, or whatever it may be, you can then set the property ProgressValue on the TaskbarItemInfo. The ProgressValue property takes values between 0.0 to 1.0.
There is a few other enum values on the ProgressState which you can explore with TaskbarItemProgressState.
Another great feature that Windows 7 has introduced into the taskbar is the notion of overlays. In a nut shell, they are simple icons that are displayed on top of the taskar icon. It’s also extremely trivial to enable for your application. Following from the same code sample from above, we simply set another property on the TaskbarItemInfo:
<Window.TaskbarItemInfo> <TaskbarItemInfo Overlay="Green.ico" /> </Window.TaskbarItemInfo>
And the result is:
There is so much more to cover with the new Windows 7 taskbar integration features that WPF 4 brings to us. I’ll blog more about it soon.
I’ve been a bit busy recently playing with my new toy (that my sister got for my birthday!)! I recently decided to get into photography, since it’s kind of like the new cool thing to do, and also, it’s quite a good feeling to take good shots, very satisfying.
Here’s what my new camera set looks like (snapped with my Canon IXUS 85IS):
Here are a few shots I just I quickly took with my new toy, it’s relatively easy to take nice shots with DSLR’s:
Once I get the hang of this camera, I’ll soon become a flickr addict!
Sometimes I don’t know whether to laugh or to cry. I have found that over the past few years, the solution to many people’s problems is one word: Controls. I’m not trying to say that controls are a bad thing, but when managers start sayings things like: “but can’t you just get a control for that?”, or, “yeah, so the screen will be like this, we wack a control, here, and here, and there, and we’ll download some control online and put it here”; it makes me burst into tears laughing, and it’s definitely not managers only, I’ve had developers say this to me as well (clearly, these guys were backend developers, I’ll go into more detail about how you determine this in a future post).
If only development was so easy, then the process of developing a solution will be something along the lines of this (in fact, I think it’s what most managers want in the future):
- Gather Requirements
- Determine Required Controls
- Drag and Drop Controls
- Configure Controls
- Test and Deploy Solution.
Don’t get me wrong, I use controls, but it’s definitely not the first thing I head to when developing a solution, mainly because of a variety of factors:
- May only require 1% of what the control does.
- Cost factors.
- Control (no pun intended), I tend to like a bit more control of things, I know some vendors provide source, but not all.
- Learning curve, this depends, I’ve dealt with some nice controls in the past, which took little time to grasp.
- I like to learn how to make things, I’m sure everyone does as well.
I find it ironic that all people can do in these so called meetings is to continuously go off tangent and talk about how good they are. It’s like a game where people get together to try their best at selling themselves. The past few days have been extremely aggravating, I cannot describe the amount of “umming’s and ahhhing’s” during a meeting. It’s not only time wasters but a good indication that there really is no agenda to the meeting.