There are some pretty great looking icons out there, with lovely drop shadows and alpha-blending, problem is they look pretty bad in Delphi since it doesn’t fully support them. Below is how I use XP-style, 32-bit png images as icons inside my Delphi applications.

Create a resource file

1. Get your image into an .ico format. I use icon sushi to convert png images into icos.
2. Create a new text file, save it as icons.rc (you can call it whatever you want).
3. Edit the file and for each icon create an icon resource entry, like this:

   icon_edit    ICON    "edit.ico"

   icon_edit is the name of the resource, this is how you’ll refer to it in code when you load it.

   ICON is the type of resource, in this case… well, you get it.

   “edit.ico” is the name of the icon file and it can include a path. A common pattern I use is to put all my icons in a folder, imaginatively named “icons” and then I include them like this:

   
   icon_edit    ICON    ".iconsedit.ico"
   icon_copy    ICON    ".iconseditcopy.ico"
   icon_paste   ICON    ".iconseditpaste.ico"

4. Compile the resource script into a resource file. I use Borland’s Resource Compiler, brcc32. To make it so I don’t have to drop down to DOS all the time I create a little batch file that I can double-click. It looks like this:

   brcc32 icons.rc
   

5. Include the resource file in your project. You can include a resource in any of your unit files but I prefer to include it in the unit from where I’ll be using it, such as the main form or a datamodule. Include it like this:

   {$R icons.res}
   

Prepare your Form

1. Add a TImageList to your form. Change the Width & Height properties to match the size of the icons you want to load (32×32 for example).
2. Download this file: uXPIcons.zip. It has routines that will enable your TImageList to support 32-bit XP style icons. I can’t take any credit for these routines. I found them on someone else’s site describing the exact same thing I am but I can’t find it anymore.
3. Unzip and add the uXPIcons.pas unit to your project.
4. Create a new procedure called “InitializeImageList()” or some other fun name.
5. Add the following code to your new procedure:

   ConvertTo32BitImageList(ImageList1);
   AddIconResourceToImageList('icon_edit', ImageList1);
   AddIconResourceToImageList('icon_copy', ImageList1);
   

6. AddIconResourceToImageList returns an integer which is the index of the icon just added, which can be used to set the GlyphIndex for any control that takes both an ImageList and a GlyphIndex.
7. Call “InitializeImageList()” from your FormCreate().
8. Run it and rock.

Update: One thing you’ll notice is that now your main application icon has been replaced by the first icon in your resource file. My suggestion is to just make sure your application icon is first in your resource file. It actually works better for me since I often have to create versions of my applications with different main icons and being able to swap them out via different resource files using a build script is much easier.

There are lessons you learn in school and there are the things you learn along the way. I’ve been developing software for 25 years, since I was 8, starting with a book called “Your First BASIC Program” that my dad bought me because we had a PC while all my friends were playing StarBlazers on their Apple IIs. He said if I wanted to play games then I could write one myself. At the time I was a bit disappointed (OK, crushed) but now… well, Dad, thank you.

These are some of the things I didn’t learn in school, but wish I had:

1. Use Version Control

Even if you’re a solo developer get into the habit of using a version control system. For one it gets you used to the concepts of version control which you’ll definitely need if you work with a larger team and secondly it offers another level of protection. My current favorite is subversion, it’s easy to install, has a great command-line and GUI client and it’s free.

One more bit, commit often. Think of commits as “undo checkpoints”. You thought replacing every instance of the base class across 50 project files was a great idea but then realized your idea sorta sucks? No problem, you can restore all 50 of those files back to their pristine state. No undo buffer will help you the way a good VCS will.

2. Use the Native Naming, Coding and Formatting Style or “When In Rome”

Before you decide to reinvent the wheel look to the native language for hints on code formatting, variable naming, indenting and method naming. Fight the urge to use your own style or to use your favorite formatting from another language. There are a few reasons:

• Maintenance. Some poor schmuck down the line will probably have to look at your code and they will probably disagree with your highly stylized use of brackets. At least the native style of formatting will be familiar to them as a common baseline.
• Fighting the IDE. If you’re using an IDE it’ll probably have some form of code completion, with some built-in templates for basic things like loops, classes, closures, etc. Those templates will more than likely be in the “native style” and you’ll either spend all your time fixing the formatting or worse you’ll create a mishmash of your style plus the IDEs, which creates confusion.
• Avoids Fights. Everyone loves to fight about how to format code, picking the native coding style means you’re the only one with an actual real argument, everything else is just opinion.
• Sharing Code. Sometimes you’ll have bits of code that don’t work and you’ll post a snippet on a forum or newsgroup. It’s much easier for everyone to help out if the code looks familiar. Anytime I see some really crazy formatted code from someone asking for help I skip right over it. I don’t have time to puzzle over their code AND their strange formatting.

3. Catalog your Knowledge

Whether it’s a blog, a wiki, del.icio.us or just a big fat txt file you’ll want a way to collect the bits. As a developer you absorb an amazing amount of information each day and you’re bound to forget that exact command-line parameter you need to get something working. Trust me, it’s easier to spend 5 minutes writing a blog post or tagging it in del.icio.us than to have to spend another 30 minutes later hunting it back down.

4. Don’t Be a Bigot

Don’t attack someone just because they don’t code in your language or tool of choice. I see so much energy wasted by people putting down one language or another. Ruby on Rails developers bashing ASP.NET coders, ASP.NET users coming down on Flash programmers, Delphi developers ripping apart .NET. Every language and framework has strengths and weaknesses and given the huge number of tools there will be many ways to accomplish the same goals, none of them more correct than the other.

5. Don’t become a Framework Programmer

I’ve sat through some pretty painful interviews when I asked basic programming questions only to answered with, “well, first I’d download this library and then…” or “I’d use this helper method…”. Then when I asked how they’d do it without that library or method I either got blank looks, or my favorite answer, “well, then it couldn’t be done”. Knowing that there are great frameworks out there, whether they be .NET, the VCL or Rails, is great, and knowing how to squeeze all the performance out of them is a worthy skill but you will always hit points where you have to go outside the framework. If you understand programming concepts you can always learn new languages pretty quickly but if all your knowledge is sunk into a single framework it’s going to make the transition rough.

Understanding programming as a concept vs. a set of syntax and framework calls also opens up a huge number of resources for you. Not every article will be written in your language and there is no reason to ignore a great idea just because it’s not tailored for your framework/language of choice.

6. Don’t just Copy And Paste Code

I have a phrase I use at work that I’m pretty sure annoys the hell out of co-workers, it goes like this, “Don’t just copy and paste code, instead copy, understand and THEN paste”. There is a wealth of code samples out there but if you don’t really understand what it is you are using then it’s going to be a pain in the arse later to debug. We all have times we just want to get something working but if you don’t really understand the code you’re using then you’re always going to be dependent upon someone else. It’s also important to remember that just because it turned up on the internet doesn’t mean it’s actually good code.

7. Understand the Sugar

Lately I’ve seen a few examples in Ruby, JavaScript and C# showing off some great syntactical sugar, shortcuts that make it easy to do things in one line that used to take five or six. They are impressive and definitely time saving but they come with a cost, usually in terms of performance.

One example is working with collections in Ruby. Someone posted a snippet showing how you could replace a “bulky, ugly for-loop” that gathered objects that met a certain criteria and then did “something” to them with a single line of Ruby code. The Ruby looked sexy, it was small, it was readable, it got ohhs and ahhs. The for-loop was the underdog at 9 lines, it used nothing but the most basic language constructs. The problem was the fact that the single-line of code actually went through the collection 4 separate times while the old-school for-loop did it in a single pass.

There are quite a few times where the sugar outweighs the performance hit but it’s important to understand what that sugar is really doing.

8. Code for Maintenance

Pretend you’re in that movie “Memento” and that you forget everything about your project every night. You should be able to figure out what’s going on the next day fairly quickly just from how the project is structured, it’s class names and coding style. Your variable names should make sense, methods should be tidy, there shouldn’t be 15 layers you have to drill through just to do something that should be simple.

Here is a dirty little secret, the easier it is for someone else to understand your code the easier it is for you to hand it off. If you’re the only one that can make sense of your code you are going to tied to that project forever. Forget getting first pick of new projects, you’re now kept in reserve incase you have to do maintenance on your project.

9. Code for Now

As developers we love to code for that future when we may need to add another database back-end or swap out a different rendering engine or port to a different platform. Guess what, unless those things are actually on some roadmap or written on a stone tablet they will either never happen or will happen in such a way that you’ll end up rewriting your code anyway. I have a ton of old projects littered with extra layers of abstraction that I’ve never needed and they’ve gotten under foot more times than they’ve been helpful.

Dirty Secret: It’s always been easier to add in a new abstraction layer than it has been to work with an existing one that was never used. If you don’t need it right now then don’t code for it.

10. Stay Abreast of the Landscape

You’ll never know everything about programming, it’s a constantly expanding landscape but it is a good idea to keep abreast of what’s going on around you. One of the things that has served me best is knowing just enough about other programming areas that I usually have pretty good idea to know where to look for things.

There is no excuse to not know a little bit about what it is going on these days. It used to be I got most of my information from magazines and newsgroups, now there are also blogs and wikis, community forums and podcasts.

Dirty Secret #1: Subscribe to at least two different sources that have different views. Everyone is biased and again, not everyone knows everything. Usually between an evangelist and a detractor you’ll come close to knowing the “real” story about something.

Dirty Secret #2: Read even the boring things. We used to get a Delphi magazine at work and at first I’d only read the articles that applied to me. I’d ignore the database and security articles because that’s not what I was working on at the time. Then I got bored and started reading the entire thing each month. Later, when I started working on a project that was heavy on DB and security I found I already knew a little something about both.

OK, disclaimer, I actually have no idea if it will or not but in the tradition of bloggers everywhere I thought I'd do a bit of overstatement to grab some eyeballs. Plus if it turns out to be true I can claim psychic powers.

After looking at a lot of WPF and Silverlight demos it seems that something like the Zune software would be a perfect fit. It allows for a much greater degree of UI customization and "prettification" while still integrating naturally into the OS. Looking at apps like Vertigo's Family.Show or thirteen23's Harmony you see the richness of UI that can be achieved while maintaining a functional application. With the Zune trying to position itself as a social, interactive device you need a software interface that mimics that immersive, social, networked experience and currently the Zune software feels about as social as watching a midnight matinee alone in an empty theatre eating stale popcorn.

Another reason is that many gripe about the Zune software being written on top of Windows Media Player 11 and while the concept doesn't bother me the fact that the Zune team is tied to the WMP team for software improvements does.

The last big reason I see the Zune software being written in Silverlight is to solve the cross-platform issue. A lot of criticism is heaped on the Zune simply because it doesn't have Mac or Linux software and while it did take a year for iTunes to come to Windows after the iPod came out newer portable media players don't quite have that luxury. I haven't done enough research to know how deeply you can hook into the OS, as I imagine you'd have to do to enable some things like the Marketplace DRM and USB device syncing, yet if it is possible you'd have a very strong poster-child for the power of developing in Silverlight.

Of course I can also see the obstacles. WPF isn't proven yet, in fact I don't believe it's even hit 1.0 status and it requires .NET 3.0, which in turn makes for a larger install with more pre-requisites. When you're talking about a consumer level device you want the software to be as easy to install on as many computers as possible and using fresh, out of the oven technology isn't always the best way to ensure a 100% trouble-free experience. Plus the developers now have twice the work-load as they not only need to push the full power of the Zune but they also need to to wrestle with learning the ins and outs of a new tech.

Given all the obstacles though I think there would be a huge benefit in writing the next Zune software version in WPF or Silverlight, both at the Zune level for the degree of interactivity to be gained and for Microsoft as a way to showcase just what WPF can do.