I welcome the name change. The word shareware has a positive ring to it for me, but I have come to realize that for most people, it only serves as an unnecessarily confusing moniker for what is now a normal means of software marketing — trying software before buying it.

Back before the Internet was ubiquitous, someone wanting to market their software without going through the normal retail channels could encourage their users to “share” the application with others, who would pay for the software if they liked what they tried.  These days, there is no need for “sharing” a disk or uploading to a BBS, since one can simply visit a website to download the program.  There is a lot of debate over what the “first” shareware program was or whether or not it was even “shareware” at all, but the point is, shareware described a software marketing method, not the software itself.

The distinction is lost, however.  Therefore, it is wise to discontinue using the term altogether.

Though I market my software with “try before you buy” download versions, I haven’t used the term “shareware” in many years, because I’d rather describe my software to someone instead of defining idiosyncratic marketing terms.  My company does what other software companies do: design and sell computer programs.

So, kudos to the ASP for getting this done and moving on.

I still have a bunch of these in a shrink wrapped box (just in case I ever want to save a new file on my Commodore 64) — but those are even more rare, because the Commodore drives use an older double-density format.

Remember those floppy disk cases that let you organize the disks like they were paper in file folders?

Interestingly (well, to me), I have old floppy disks from the eighties that have outlasted burned DVDs and CDs from the early 2000s.

Been busy.

SwordSearcher Bible Software version 6 is now available. 2010 marks the 15th anniversary of SwordSearcher.

I love my job!

Lots of details here and here. Also got a video of some of the new features here.

I’ve recently created a SwordSearcher fan page on Facebook, too.

So, I’m starting up a web design service: Vexelfire.

Vexelfire: Design is the first impression.

A stock Delphi TToolBar will paint with a flat color or with a gradient. This is how a plain TToolBar appears in Windows Vista and Windows 7:

It looks okay, but Windows Vista has been around for a long time now, and this toolbar looks a bit dated. It doesn’t scream "old," but it certainly doesn’t pop out as "shiny."

What we want to do is have the toolbar paint its background with the current operating system theme. This will give us a nice toolbar look that conforms to the current them, looks modern, and is backwards-compatible with Windows XP. Delphi (2007 and 2009) doesn’t offer us a property to do this, so we need to add some code to the toolbar’s OnCustomDraw event.

First, we add Themes to the form’s uses clause. The Themes unit contains Delphi routines for accessing the Windows XP and Vista Theme API.

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ComCtrls, ImgList, ToolWin, StdCtrls, Menus, Themes;

Next, add the TToolBar’s OnCustomDraw event handler (double-click it under Events in the Object Inspector). And add the code to paint the background:

procedure TForm1.ToolBar1CustomDraw(Sender: TToolBar; const ARect: TRect;
  var DefaultDraw: Boolean);
var
  ElementDetails: TThemedElementDetails;
begin
  if ThemeServices.ThemesEnabled then
  begin
    ElementDetails := ThemeServices.GetElementDetails(trRebarRoot);
    ThemeServices.DrawElement(Sender.Canvas.Handle, ElementDetails, Sender.ClientRect);
  end;
end;

A little explanation:

ThemeServices.ThemesEnabled lets us know Themes are actually being used, so we don’t try to paint a theme element on a system that isn’t using themes.

The record variable ElementDetails is used to tell Windows what kind of theme object we want painted. In this case, we are using the rebar background, specified with a call to ThemeServices.GetElementDetails(trRebarRoot). We use ThemeServices.DrawElement to paint the rebar background on the TToolBar’s canvas.

This is how our Toolbar looks now:

With just a few lines of code, our application looks like it has had a major face lift.

There is still something left that can be done to improve the appearance of the form a little more. Ideally, the toolbar should be blended a bit with the menu above it. You only need to do this if you are using a standard TMainMenu on the form’s Menu property to display your menu.

Change the OnCustomDraw event handler for the TToolBar so it looks like this:

procedure TForm1.ToolBar1CustomDraw(Sender: TToolBar; const ARect: TRect;
  var DefaultDraw: Boolean);
var
  ElementDetails: TThemedElementDetails;
  NewRect : TRect;
begin
  if ThemeServices.ThemesEnabled then
  begin
    NewRect := Sender.ClientRect;
    NewRect.Top := NewRect.Top - GetSystemMetrics(SM_CYMENU);
    ElementDetails := ThemeServices.GetElementDetails(trRebarRoot);
    ThemeServices.DrawElement(Sender.Canvas.Handle, ElementDetails, NewRect);
  end;
end;

What we’ve done is introduced a new TRect so we can modify where the background painting starts. NewRect is initialized to the toolbar’s client rect coordinates. Then we use a call to GetSystemMetrics to get the height of a menu bar, and subtract that from the top of NewRect, and pass NewRect as the drawing rectangle to DrawElement. This starts the rebar background at the same position of the menu, giving us a more blended look for the toolbar:

Now the toolbar looks more "attached" to the menu bar.

Note that the toolbar paints well under Windows XP, too:

Giving a stock TToolBar a modern-looking background only takes a few lines of code and is an easy way to improve the appearance of your application. Once you’ve done this, you’ll want to start poking around in Themes.pas to see what else you can add some theme magic to.

New in this release is support for Unicode text and visual improvements (especially for Windows Vista and Windows 7).

For me, programming is usually a creative process. Unless I am fixing small bugs or making minor tweaks, writing software is no different from writing a story, a song, a poem, or drawing a picture. It is an abstract process by which I turn general ideas into something that doesn’t quite approach a true language. There is a purely creative process: coming up with ideas to implement. And there is a less creative, but often just as abstract a process: turning those ideas into little processes that a compiler can understand.

Since writing code is so much like writing anything else, a programmer is prone to “programmer’s block” just as an author of a novel can be afflicted with writer’s block.

Beating programmer’s block while simultaneously staying productive is something easily done as long as you keep these things in mind:

• When you’re stuck, do something else.
• It’s easy to do something else if you have more than one project.

It’s really that simple, at least for me. At any given time I have at least a half-dozen “things” I can do that constitute productive behavior.  If I experience programmer’s block when developing one application, I have several others I can go work on for a while. Or, I can write a blog entry or even read a business-related book.

The key is to have more than one thing to do at any given time, so that when project A gets stuck, you can go work on project B for a while.  It’s not hard. And for me, the goal is to take a break without becomming idle.  Sure, vacations and long-term breaks have their place, but with all those people on welfare counting on my taxes, I just can’t relax when I am truly doing nothing so I always have something else I can do when I hit a wall.