The best 330 MB of my C: drive...

Well, I hate to be negative about stuff, I really do, but I just can't help it. Having fought so many times with a lacking help system, I finally decided it was time to uninstall it. It's pretty useless to me as if I want MS docs I'll search for them on the net and they will be more up to date. So, I finally decided to go to Add-Remove Programs and Change the Rad Studio installation to remove those help files.

In doing so, I found out a few more things:

1. Install-aware sucks even more than I thought! What used to be a few seconds on a decent installer takes over 6 minutes to do in this Install-Aware setup!
2. They use a lot of progress bars but really show no progress: a blinking light would show the same information... At one point 2 were present at once and really I could be no closer or farther away from knowing how much more time I'd have to wait as they were file-based progress bars and not *process* based ones...
3. What the heck is a "Cach"? As in "Removing Cach folder xxx"
4. Shouldn't I get a more graceful message when pressing F1 on RAD Studio if I chose to remove the help files? (in a legitimate way and not hacking the files!)
   And the message even shows in Portuguese even though my Windows and RAD Studio are both English...
   
5. Finally, if I chose to remove the cached install files, what are 100 MB left there for?

This is all a nasty combo of a lousy installer with probably some lousy install scripts...

Q: Would I uninstall Delphi 2007?

A: Well, I've got used to it and it works well overall so most likely no, I'll keep using it. I just got fed up with the so labeled "Improved Help"... Pitty that MSFT set the road that others followed by releasing unfinished software...

For those who may not like me "bitching" about this: would you like to buy a car that "sort of works"? And that has to go through a few Service Packs before you really got what you're promised it would be before purchasing? I'm just applying the same principle to Software...

[EDIT: I've just "fixed" that error message: removed the htmlhelp2100.bpl (or something like that) from the known IDE packages so now pressing F1 silently fails. I'll probably try and find some replacement help files/reader as I vaguely remember something about using previous versions help files. Then I'll try downloading those help files from the customer area if it works! :)]

No comments...

Well, I lied! I have one comment: I did press the feedback link, even though the question looks almost a joke! :)

BTW: The Void stamp and yellow highlighting is just me playing around with SnagIt! :)

EDIT: It appears it gets even better:

Delphi "killed" by VB6? WTF?

Well, I read in TWM's blog that Delphi is listed in the 12 languages that never took off.

Since I can't comment on either page, I decided to comment in my blog...

I can only say one thing: that article reminds one of the languages mentioned in it (the one that starts with brain...); that article is surely someone's brain fart!

Saying that VB6 killed Delphi and showing a stupid piece of partial code as if it's a "hello world" program???

And for those that would accuse me of attacking that article because I'm a Delphi fan-boy: just read my blogs here and you'll know that I'm everything but a fan-boy!

But I also don't like to see some moron (sorry, but can't help to use that word), say such things about Delphi.

Is that guy getting paid from MSFT or something? Or is he just a dumb arse?

[Edit:]

I've since gone to digg.com and checked out who blogged about that digg among other things: it turns out that my impression that digg was just full of meaningless trash is correct! Of those that "blogged" about that digg, nearly all are non-related commercial sites of some sort that are probably just using some robot-like technology to crank up their site in the listings!

Now, I already thought that digg was a waste of time but now I know for sure that it is really a waste of time! At least that dumb article had some usefulness! :)

Command line: do you still use it?

Well, I do and for quite some years I've been using JPSoft's 4NT. I have some nice batch files, custom prompts, custom functions and it has a whole lot of built-in commands, variables and functions as well.

But, not only do I find myself doing less actual command line stuff, I sometimes get a bit mad at this product, like yesterday when I was attempting to use drive aliases inside a function and later found out that it doesn't work there, only in commands... Kind of the legacy from a program that, the author has admitted, has a ton of different parsers for a ton of different functions/commands. It's also partly due to the fact of maintaining compatibility with command.com and cmd.exe in their many versions and changes so far, but sometimes I think that it would be better to use something else for my command line scripting, perhaps something that doesn't carry this legacy compat baggage and thus can have a more uniform and predictable syntax.

Which brings me to the question: do you still do comand line? What tools/programs do you use for it? Or do you rely on good old fashioned cmd.exe for your command line work?

I've once tried to use PowerShell from MSFT, but, not only did it still have a lot of rough edges (like, for instance, not being able to easily work on files with some valid dos file name characters!), and, even though it is a very considerable change from cmd.exe, and sure looks powerful, it wasn't that much better than cmd.exe and even a bit lacking in many basic functions, at least a couple years ago when I tested it!

So, if you have a nice experience with something other than 4NT/CMD/COMMAND, let me know what you use and how happy you're about it and I may even go and try that for a change!

Quick tip for compiling/testing DLLs

Now that Delphi 2007 is using MSBuild, you can take advantage of the Pre-Build events to automate a common headache: killing that task that is using your DLL before you build it!

I'm currently developing an Outlook add-in so I found myself repeatedly quitting Outlook or getting an error because Delphi can't generate the DLL if I don't close Outlook, so, to solve that, and since, for some weird reason, I got used to always build instead of compiling, I just added the following command to this project's Pre-Build Events:

taskkill /F /IM outlook.exe

DIR >NUL

And that's all there is to it. You can also launch outlook after the build so as to immediately test your changes by adding the proper command to the Post-Build events, but I didn't add that as sometimes I do a few builds just to check syntax/compiler errors while I'm still working on something and I don't want to have outlook popup everytime...

Also, you can try without /F (force) and if your outlook or dll host can terminate gracefully in a speedy way you won't need to force termination, but in my PC and with Outlook it doesn't quit that fast, so I need the /F...

EDIT: The DIR >NUL command is just so that, should you not currently have outlook running, the error from taskkill won't stop your build process! :)

BTW: you can achieve something similar in BDS 2006 (and maybe 2005: haven't tested on this one), if you read my blog post about adding pre/post build events to BDS 2006...

Code formatting and readability

Well, each developer tends to have his own set of rules be that for code formatting, identifier naming or whatever. And each developer, when looking at someone else's code tends to go like: "wow: what was this guy thinking?"...

Here's a piece of auto-generated code from Add-In Express:

    procedure ActivateEvent(Sender: TObject);
    procedure ClickEvent(Sender: TObject);
    procedure CreateEvent(Sender: TObject);
    procedure DblClickEvent(Sender: TObject);
    procedure DeactivateEvent(Sender: TObject);
    procedure DestroyEvent(Sender: TObject);
    procedure KeyPressEvent(Sender: TObject; var Key: Char);
    procedure PaintEvent(Sender: TObject);

I find this very annoying and hard to read/browse! So, even though I know it serves no useful purpose other than please my eyesight, I turn that into something like this:

    procedure ActivateEvent  ( Sender: TObject );
    procedure ClickEvent     ( Sender: TObject );
    procedure CreateEvent    ( Sender: TObject );
    procedure DblClickEvent  ( Sender: TObject );
    procedure DeactivateEvent( Sender: TObject );
    procedure DestroyEvent   ( Sender: TObject );
    procedure KeyPressEvent  ( Sender: TObject; var Key: Char);
    procedure PaintEvent     ( Sender: TObject );

Now, isn't this 2nd version much easier on the eyes? Surely it compiles the same as the 1st one no faster nor slower no more and no less bytes used, but for us, humans, it's way easier to look at!

Heck, I even do this on forms after they are stable enough and I know I won't be adding too much stuff/events to it! :) And if I do add, I'll re-sort and re-format those lines! :)

There are a ton more of things I change for cosmetic reasons, such as placing begin/end on pretty much every single if, even if it really wasn't needed (there are exceptions mainly when the one-liner if's are used as a sort of case construct where keeping them one-lined does help readability).

Again, a small sample:

  if FPropertyPageSite = nil then
    if Assigned(ActiveFormControl) then
      if Assigned(ActiveFormControl.ClientSite) then
        ActiveFormControl.ClientSite.QueryInterface( IID_PropertyPageSite, FPropertyPageSite );

And, after reformatting:

  if FPropertyPageSite = nil then begin
    if Assigned(ActiveFormControl) then begin
      if Assigned(ActiveFormControl.ClientSite) then begin
        ActiveFormControl.ClientSite.QueryInterface( IID_PropertyPageSite, FPropertyPageSite );
      end;
    end;
  end;

Now, you may think that there is not much difference in here, but there is! Especially if some have begin/end and others don't and depending on what code follows. Plus, always using begin/end means you don't need to look too hard on the code as to where to place the begin/end pair when instead of a single line inside a multiple if you need to have two lines of code: all the code layout is perfectly done and you just add that extra line where you want it without much trouble...

There are many more things that I change, even in code that is not my own as long as I'm the only one using it and as long as I need to change/edit/maintain it, but I thought of these as I was making some changes to this code and figured I'd take a few mins break and blog about it! :)

Also, you can take advantage of Delphi's built-in begin/end helper: just type begin at the end of a line, place your cursor to the end of the last line of the code block to be enclosed and press enter: et voilá, instant end properly lined up, courtesy of Dephi's IDE... :)

[EDIT: I knew I was being lazy with the begin/end/if example so here's a better one...]

// Messy version
begin
  Result := (AControl.Handle = Focused);
  if not Result then
    for i := 0 to AControl.ControlCount - 1 do
      if AControl.Controls[i] is TWinControl then
        if TWinControl(AControl.Controls[i]).Handle = Focused then
          Result := True;
        else
          if TWinControl(AControl.Controls[i]).ControlCount > 0 then
            Result := SearchForHWND(TWinControl(AControl.Controls[i]), Focused);
end;

// Cleaned up version
begin
  Result := (AControl.Handle = Focused);
  if not Result then begin
    for i := 0 to AControl.ControlCount - 1 do begin
      if AControl.Controls[i] is TWinControl then begin
        if TWinControl(AControl.Controls[i]).Handle = Focused then begin
          Result := True;
        end else begin
          if TWinControl(AControl.Controls[i]).ControlCount > 0 then begin
            Result := SearchForHWND(TWinControl(AControl.Controls[i]), Focused);
          end;
        end;
      end;
    end;
  end;
end;

Of the two pieces of identical code, which one do you think is easier to add something to? Say an else to one of the if's or some other instruction in any of the "branches"... And note that, the indentation on the messy one is not that messy and it helps a bit, but you sure can follow the cleaned up version better when trying to see all possible outcomes from that function, no? It certainly works much better for me at least! :)

Bugsie - Part 2

In my previous post, I mentioned a minor layout bug that I watched during the CodeRage Encore presentations. I can now consistently replicate it but other people have mixed success depending on what system they use. Here are the necessary steps to reproduce that show that it is in fact a question of the IDE not redrawing the gray/black corner handles.

1. File -> New Form
2. Add 2 buttons to the form such that they're not aligned
3. Drag a selection rectangle and note which button has darker corner handles
4. Right-Click the other button, that is, the one with the lighter corners
5. Select Position -> Align -> Cancel
6. At this point, if the bug happens on your system, the corner grabbing rectangles should not have changed colors, i.e., the button with the darker corners is still the same
7. If step 6 happens on your system, then click the Align Tops on the Align toolbar and see that the anchor button was the wrong button!

Now, I said that you could see that it was a display issue. Here's how to do that:

1. Repeat steps 1-5 on the above list
2. If, after step 5, you can confirm that the button corner handles haven't changed color, i.e., bug is happening, then simply open up something that will cover the form so as to force Delphi to later redraw it (Internet Explorer, FireFox, Explorer, Outlook, etc)
3. When you move that window away (or switch back to Delphi), you will see that the darker corners are now properly displayed.

Here's the QC report created on this one:

Report No: 48631          Status: Reported
Form designer may fail to correctly update changed anchors
http://qc.codegear.com/wc/qcmain.aspx?d=48631

BTW, if you need more information on the black/gray corner handles, check this post from Steve Trefethen...

Can you confirm this bug?

Well, 3 months ago, when watching one of the CodeRage Encore presentations, I witnessed a bug in action (more on that sooner!); even though I tried (as you can see in the replay), I couldn't get the presenter to replicate the bug. Now that the replays are finally available and now that I know how to skip so as to quickly find out which presentation and at what point it was (3 months make you forget a lot of stuff, especially when you were thinking the replays would be on after a week or so!), I've finally confirmed that I did indeed saw a bug.

Can you please go here, wait for the video to fully stream (progress bar fully light gray) and then position a few seconds before 06:38 where the bug happens and confirm that it is indeed a bug? I'll report it in QC as soon as I get some 3rd party confirmation on that.

Here's the bug: if you notice in that presentation, there are 3 buttons selected; the middle button has darker corners meaning that it's the button that is used to "control" the action, that is, whatever you choose it relates to that button. Notice that, when selecting the "Align top" the 3 buttons are (incorrectly!) aligned to the first button's top and not to the one with the darker corners. (Watch the video from the start for the explanation on the dark corners). [Edit: the dark corners are either explained elsewhere or later in the video, not before!]

If you can confirm what I saw, then please leave a comment here.

(CodeGear should probably hire me for finding bugs for them, but since I do it for free anyway, I don't think they want to! :))

[EDIT:]

Actually, at first, after making this blog post, I thought it could be some Camtasia bug as I could not reproduce it (as I right-clicked the top-left button it was selected); I have however been able to replicate it afterwards!

Here are the full steps:

1) File->New Form
2) Double click 3 times on TButton
3) Grab button 3 to top left
4) Grab button 2 to mid right
5) Drag a selection box from upper-left to lower-right

At this point, Button 1 is selected;

6) Right-click Button 3
7) Choose Position->Align from the menu and Cancel

At this point, Button 1 still appears to be selected.

8) Click on Align Tops in the Align toolbar and get the wrong behavior doing the align with Button 3 instead.

It appears that Button 3 was in fact selected by right-clicking and that the designer didn't redraw to show that.

BTW: Using Delphi 2007 SP1 on Windows XP with theming active.

CodeGear Replays: not entirely their fault... :)

Well, after my previous post, and after some comment left in by a reader, I decided to "bug" Anders (not knowing he's on vacation!), and it appears that the problem with the video not skipping to where you try to skip is Camtasia's fault... Having tried Camtasia in the past, and seeing how many "helper" files it generates and all of them including the video duration, I would expect it to be able to do something as simple as positioning the video cursor somewhere where the video has already streamed (you can tell by the bar color, gradually filling with a lighter gray where it has already streamed).

It appears that instead, you have to wait until the whole video has finished streaming before you can reliably position the video playback cursor somewhere! I just browsed some of their own videos and noticed that they too suffer from the same problem so it does not look like it's CodeGear to blame on this one! :)

On the plus side, Anders also said he might be looking at making the download links available after returning from his vacation next week...

For now, you can start the playback of any video, pause it (if you don't want to be listening to it while it streams), and when the progress bar has completely filled light gray, you can then position the playback cursor wherever you want and use that as a quick way to skip past content that you want to, well, skip! :)