Win32 thread names in the Delphi IDE

The Delphi help only mentions how to do this using C++, and Google doesn't provide the solution in Pascal easily, so I thought that I'd better publish the solution here. In order to see names for your threads in the Delphi IDE while debugging your Win32 application, call SetCurrentThreadName() in your TThread.Execute method:

procedure SetCurrentThreadName(const Name: string);
type
  TThreadNameInfo =
    record
      RecType: LongWord;
      Name: PChar;
      ThreadID: LongWord;
      Flags: LongWord;
    end;
var
  info:TThreadNameInfo;
begin
  // This code is extremely strange, but it's the documented way of doing it!
  info.RecType:=$1000;
  info.Name:=PChar(Name);
  info.ThreadID:=$FFFFFFFF;
  info.Flags:=0;
  try
    RaiseException($406D1388, 0, 
      SizeOf(info) div SizeOf(LongWord), PDWord(@info));
  except
  end;
end;

Let's hope it gets easier to find on Google now.

Code style of old age programmers

It seems that I have the same age as Jeff Atwood, but somehow not, when I read his latest post. Somehow I feel "been there, done that", because I would almost have agreed with him 10 years ago, while still being a freelance programmer, helping out in various programming teams. However, today I'd definitely say that maintainability is much more important than most programmers want to acknowledge.

Most programmers spend most of their time maintaining code, not writing new code. They may spend time on maintaining their own code - but it's still about maintenance. And actually, they spend much more time per SLOC when doing maintenance, than when writing new code. In other words, in order to be really productive, it's the maintenance part that needs to be optimized, unless you're doing a quick and dirty application that nobody is going to use (yeah, right!). The perfect source code is when it works perfectly AND cannot be easier to maintain. This includes simplicity, of course, but it also includes comments, understandable variable names, well defined context and well defined invariants.

When to hide or disable menu items and buttons

I often disagree with Joel, also in his latest post about menu items. Hiding and disabling buttons and menu items is usually done in order to prevent, that the user triggers an event, and it's perfectly ok to do in some cases:

• Hide buttons that the user wouldn't search for. For instance, a non-administrative user doesn't need to see the Admin button.
  
  
• Disable buttons where it is obvious to the user why it isn't clickable. For instance, a well implemented undo functionality doesn't need to have it's menu item enabled before the user starts editing. That would actually confuse some users.
  
  
• In all other cases, make the button visible and enabled, but show a message that explains to the user, why this functionality is currently not available, and what the user can do to make it available.