Did CodeGear rush out 2 Delphi products?

I've made a few comments on other blogs about it, but I think I should take the time to better explain my point of view with a full blog entry...

Did CodeGear release Delphi 2007 for Win32 and Delphi for PHP before they were ready for release?
In my opinion: Yes.

Why do I think that, you may ask?

Well, for quite a number of reasons that I will enumerate:

1. When I first asked some of their online retailers when they were expecting to ship Delphi for Win32, the answer was "first half of April": a few days later the product was released, 3~4 weeks before the expected date;
2. Judging from my own and many other customer's experiences, most of their shops/retailers were not ready to start shipping/selling the product;
3. The whole ESD (Electronic Software Download) experience was not fully tested/working when it started; the first few days of official ESD sales where a bit chaotic in some places, such as the UK, for instance;
   
4. Even though much has been said about Delphi 2007's stability, the fact is that I managed to crash it quite a few times, even without trying and even after installing on a clean machine; On my account alone, 4 Automated Incident Reports were made within the 1st 4 days of use, and that was after I noticed that I could expand the crash dialog to show a send button. Since these automated reports are marked private as they contain some information on the user's computer/processes, I can't tell how many other crash reports were made since Delphi 2007's release, but I've read about other user's similar experiences on some newsgroups;
   
5. A "simple" bug was known and a "tough decision" was made of releasing the product even knowing it was not fixed. (If you have D2007, you can test for yourself: open up any menu and press F1: if you're lucky enough to get an error for not finding the help context, the menus become unusable until you restart the IDE. This happens on most (all?) menu entries.)
6. I don't have Delphi for PHP, but from comments I've been reading on the web, even attempting to deploy some simple projects will fail to include all needed files;
7. There is a 1 day (ONE day!) trial of Delphi for PHP. Why 1 day? Well, if they gave 30 days, two things could and would happen:
   
1. People would have enough time to find out that it is an unfinished product;
2. Even if they decided to purchase, that purchase would only take effect after the 1st Quarter of 2007 had ended.
8. Even knowing that they were having so many problems fulfilling orders and back-orders, a special event took place on the 29th of March (last business day) that was available only to registered Delphi 2007 users: this was another move to persuade some more customers to buy before the end of the 1st Quarter.

[Edit] As I suspected, there's now a 14 day trial of Delphi for PHP... No more rush to make sales in 1st Quarter, I'd guess! :)

Why did they do it?

In one word: SOX. It was clearly a financial decision: the only way for them to cash in on the pre-orders in the 1st Quarter was to actually ship the products in the first quarter. The same SOX rules that prevent them from publishing the roadmap, at the risk of only cashing in when they deliver on the roadmap, was the main drive to release the products before they were ready, so that the money could be accounted for in the 1st Quarter of 2007.
[Edit]: CodeGear has now a new CEO. That could also account for why it was so important to rush those two products: making sure Ben was credited for those sales and not Jim, and thus ensuring Ben would get the proper sized bonus...

Now, some people may argue that this is just some conspiracy theory. I hope, for CodeGear's sake, that they're right. But I can say only 3 more things to wrap this up:

1. If this is not just a conspiracy theory, then they aren't starting with the right foot;
2. At least they're being more honest now with the new logo: no longer has the "Where developers matter" motto;
3. Finally, and while they do have to comply with management decisions such as these, CodeGear's employees have been very helpful in solving mine and many other developer's problems, although they would not have so many issues if they didn't rush out the products out the door to make sales in the 1st Quarter...
   

CodeRage Encore - Another view

I know many people, especially CodeGear employees, will be blogging about this, so I decided not to write about the event itself, but rather show some statistics that I compiled during those 24 hours.

The last 2 hours were in Japanese. For those, around 50 users were online which, discounting CG staff and a couple "foreign" viewers like myself, accounts for over 40 Japanese viewers. (More on that later).

For the first 22 hours, there was roughly a total of 142 different viewers, being the peak at any one time at slightly over 80. Of those viewers, here's the country roundup (after discounting CodeGear employees and presenters/moderators):

Undetermined	32
USA	17
Other	14
Japan	12
Germany	10
Sweden	10
UK	8
Netherlands	7
Italy	4
Australia	3
California	3
Canada	3
New Zealand	3

The difference between Undetermined and Other is that the 1st category is for those who either used cryptic names or about whom I could not find enough information on the web to determine where they were from. As for the Other category, includes countries with only 1 or 2 people, like my very own Portugal.

These numbers are just estimates and you can see there is a large number of Undetermined, so that could "turn the tables", but I think they do give a nice idea of who were the early adopters of Delphi 2007 (as this was a closed conference for Delphi 2007 registered users, users with current SA contracts or which had already ordered but not yet received Delphi 2007).

You can see from the table above that the Japanese are on the front line: in their "own" session, they clearly outnumbered any other single country! Also, quite a few (those listed on the table above) attended the English sessions too making them 2nd only to the USA!

Disclaimer: like I said, those results were compiled semi-manually (I ran a SHIFT-PRTSCR around every 30 minutes on the participants list, which was what I had assigned the "Capture Text from Window" option in SnagIt), then I copied all that into a single file that I sorted and used to gather more information on the web. I could have taken the time to write a small program for automating it but I was feeling lazy! :) Besides, the hardest part was finding information on *where* those people where from, and that is something I could not automate in a reliable way...

So, this was an alternate view of the event. As for what was there, there will surely be a lot more people blogging about it!

Delphi for Win32 - Part 12 (One week of Delphi)

Well, how was my first week of Delphi 2007?

Overall, I'd say pretty positive. Did get a few deceptions on it not being perfect and still a bit far from it, but it turns out to be very stable once I know what not to do.

It's also sad to see some long lasting bugs remain, such as Error Insight not always working properly after a few hours coding and needing a restart of the IDE to be able to know some unit you have on your uses clause...

But, there are quite a few things that make up for that. And thus I get to my "5 favorite things" in Delphi 2007, as it seems to be customary! :)

So, here's the list and I'll explain a bit after:

1. QC Client bundled in;
2. Speed;
3. MSBuild;
4. Improved help;
5. Improved debugger.

Of these, I hope number 1 will no longer be there in a couple months! :)

Why these 5?

1. QC Client bundled in makes it easier for lazy people like myself to check QC and add new bug reports there; this in turn means more bugs found and more bugs fixed, so everyone wins.
2. Speed: kind of obvious no? Just to make it more clear, it's IDE launching speed, (re-)opening projects, even compiling: all faster and that saves me time in the long run...
3. MSBuild: I can finally press RUN and have my COM Add-in be compiled, linked, run the protective wrapper as a post-build task, launch the host app and presto: I'm debugging. No more "attach to running process" just because I need to run a protective wrapper after compiling...
4. Even though I've grown a bit unused of trying to look up things in help, this may change with Delphi 2007: generally, when I press F1 over something, it will open in the proper place without stopping to ask for useless options...
5. Being able to use dockable parts of the debugger so I can set it my way; getting rid of unwanted stuff like instruction opcodes because I don't need them most of the time and I can use the extra space (knowing I can always turn them back on). There was a sleuth of minor and not so minor things done to the debugger that really improved it.

I guess it's pretty clear I won't go back to any previous Delphi/BDS any time soon... :)

Let's hope that CodeGear does listen to their customers, learns from those things that did not work out very good this time and, above all, produces nice and quick fixes to the major annoyances so as to iron out the last few rough edges of Delphi 2007 and making it the best Delphi ever...

Delphi for Win32 - Part 11 (Don't abuse F1!)

Well, I've been using Delphi 2007 for Win32 to make a few changes to my current project. After passing the initial couple AVs, it has been running pretty smooth and damn fast! But that does not mean that I don't run into things! So far, I have posted 24 QC entries regarding Delphi 2007 or QC Client (mostly about Delphi 2007 and mostly non-critical). Even though only 4 were the direct result of crashes/lockups, still it's a count a bit bigger than I was expecting, after all that was written on Delphi 2007....

I've now set up a "clean" Virtual Machine with nothing but Windows, updates and Delphi 2007. This is were I go and test my bugs before submitting them so that I can be sure that it's nothing related to my build and/or third-party controls. I also try and post some screen shots of the bugs in action whenever appropriate...

Now for the subject: the last bug I got was a simple case of "No help found for context". Not really much in and by itself, if it were not for two things:

1. How easy it was to get it (just open the Run menu and press F1 over some item); It may work on other menus, but I don't feel like trying!
   
2. How drastic it was! After receiving that one, the menus stopped working! Whenever I'd mouse over one, I'd get a couple different ones (see image below), and the menus would still not work. Only way out of that loop: ALT-F4 and reload the IDE.

Now, I do understand that a lot of testing was done on Delphi 2007, but maybe CodeGear should start thinking seriously about extending the beta tests to more people out there: this bug is just too easy to run into, especially when they tell us that there's an improved help, so one may just feel tempted to try it out! Maybe they need some "casual users" on their test group, people who actually try and use the simplest of things and are not focusing on trying to find such tiny cracks that they miss out on the big ones...

So, just stick with pressing F1 over components and/or keywords/properties in the editor and don't abuse F1, or you'll have to restart your IDE!

Delphi for Win32 - Part 10 (Go CodeGear!)

I've been blogging my own experiences on the brand new Delphi 2007 for Win32. Overall, it's been a nice experience, with some bumps, and the initial shock of it not being perfect...

However, I must now put out a good word for CodeGear staff: both DavidI and Michael Swindell helped me get it ordered on the first "official" day it was out, meaning that I was installing it on the 2nd day (not as good as the claimed "Instant Gratification" of ESD but not nearly as bad as waiting 2 or 3 weeks for some DVD!).

And now, I was also pleasantly surprised when I checked on the 18 QC reports I made about Delphi 2007: (Whoa! 18? Yep, but almost all were just minor nuisances and only a couple were more troublesome and even those were easily overcome.)

• 8 of those were already submitted internally;
• 2 were closed as "Cannot fix" (the ones of a "Visual Studio 2005" folder showing up on "My Documents" whenever you run the help and about a "Help improve visual studio" message that popped once);
• 1 closed for being "As designed" (Empty toolbar "Personality" showing up by default, when this is a "single" personality product);
• 3 other closed for "Cannot Reproduce";
• That leaves only 4 with no other indication.
  

Overall, this means that someone has actually done some preprocessing on those reports only a few hours after they were added to QC. I hope this will translate to faster hot-fixes, but it does show one thing: CodeGear may not have it perfect yet, but they do show they're trying...

Delphi for Win32 - Part 9 (How I like "clear" messages!)

In my setup, after installing Delphi for Win32 2007, I removed the installation folder from my C: drive (that's "only" 1.6 GB of data that does not need to be there). I always do a ghost image, so adding 1.6 GB of needless data (+another 600 MB for the .NET 2.0 SDK install files that get duplicated elsewhere), would simply mean that my image would use twice as much space for no good reason. (See my post about the install and disk space usage)

However, it turns out that Delphi is trying to somehow, for some reason (check for updates?), load the setup.exe file as you can see from the message below. Double clicking on that "weird" message ("The window does not have scrollbars") does show a more clear message of what's going on, but wouldn't it be better to just say "program not found" instead of "The window does not have scrollbars"??? :)

Delphi for Win32 - Part 8 (Time to sleep...)

The first hours spent with Delphi 2007 were like going cross-country on a city-car: not the most pleasant journey. Ran into a few bugs/lockouts which I wasn't expecting after so much was said and done about Delphi 2007's rock solid stability...

Still, not all was bad: rebuilt my dev machine and it's faster than ever, I have also converted my current project where I used my own hack to do post-build operations from within the IDE in BDS 2006 and I'm now using Delphi 2007's new Post Build Events. In a way, they're not as flexible as the way I was doing it: I can't add my *.ARM file to my project because I can no longer tell Delphi 2007 what to do with it (no more "Build Tools"), and so I have to use explicit paths/filenames in the new Post Build Events instead of having a "general purpose" way of doing it to any *.ARM file I added to my project.

Still, this new process is better for one reason alone: when I use "run" to test my office add-in in the proper office program, the IDE will now also run the Armadillo wrapper which means I can more easily debug my add-in, which was a bit troublesome in BDS 2006 with my "hack" as it kept insisting in compiling my main dll without doing a build all which is a mandatory step in the way I was doing it...

All in all, I am a bit disappointed at Delphi 2007. Mostly about stability so far, and a few minor nuisances, but I was expecting it to be nothing short than perfect after reading so many good words about it...

In the next few days, I'll try and get some work done, expecting to get much less hang-ups (preferably none!).

Delphi for Win32 - Part 7 (RockSolid := false)

Well, I honestly, really did think my next post would be about the good in Delphi for Win32 2007, but it turns out that I managed to crash the IDE once more! :( And the worst part of it is that I'm not even trying to do it! I was just trying to setup some Post Build event and experimenting around, because the "much improved documentation" not only describes the build options incorrectly, it also gives no examples of what things one can achieve and how... Now, after consistently crashing every single time I did my builds, it mysteriously stopped crashing when I changed the post build events and doesn't want to crash again even after restoring them to what they were before! Should have made a full folder backup... Now I won't be able to properly submit a bug report... :( [Note to self: start hitting PRT-SCR!]

So far, I can't say that Delphi 2007 has met my expectations... Maybe it's because they were set too high, but if that was the case, it's CodeGear, CodeRage and all those bloggers around that praised Delphi 2007 so much making everyone believe it was rock solid... Like I said above, BDS 2006 had been more rock solid than Delphi 2007 is proving to be...

On the plus side, Delphi 2007 is faster, reloads and re-opens projects faster, and, my #1 favorite feature (as it's the one I've been using most so far!) is the integrated QC client! At least one can now send bug reports in a quicker way...

Just wish I had not used the QC client at all! :(

Delphi for Win32 - Part 6 (24 Hours with Delphi)

Well, the following are just a few initial notes that I've been keeping on a text file as I go: I'll probably update this post later to better reformat it and maybe add some explanation, but right now is baby bath time... :)

Please note that the following are mostly the "nuisances" that I come across. There's plenty good things and I'll be blogging about those later!

Minor issues:

1) One of the steps in the registration dialog show incorrectly at 120 DPI (my laptop's default setting);

2) Some standard toolbars, sometimes, show a bit taller than the other toolbars (when Windows XP is set to use Themes and not sure if it has something to do with using Large Icons);

3) The Personality toolbar shows by default, even though it's empty;

4) They could have changed the BDS File and BDS Folder icons in BDS.EXE (not to speak of the main .EXE icon!); changing BDS.EXE to something else would probably break something, but they could have done it anyway and simply add a BDS.EXE stub to load the main new RAD...

5) BDSUSERDIR is set to "RAD Studio\5.0" inside My Documents but there's no such folder: there's a "RAD Studio\Projects" and "RAD Studio\code_templates".

6) Why does it insist in cluttering "My Documents" with a "Visual Studio 2005" folder *each* time I run BDS?? [EDIT: It's not every time I run the BDS, only every time I use the Help.]

7) Why not ship a more recent GDIPLUS.DLL with the product? Since I don't know which one it's being used by the integrated browser, it's better safe than sorry... (I did replace the supplied "5.1.3102.1360 (xpsp2.040109-1800)" with a newer "6.0.3275.0" and it appears to be working ok).

8) "Help make Visual Studio Better" prompt. Why? It kind of detracts (regardless of the actual reason), when a RAD selling company advertises another, even if indirectly. Should I make the move to Microsoft and stop using CodeGear products, is that the message that you're trying to convey here? Does not look good...

9) The number of different project files! Which one do I open? Minor nuisance as I simply add my "work" projects to the favorites and open from there...

Important issues:

1) Non-breaking release: well, sort of. Since they changed install folder and reg keys, any IDE/3rd party component that does not recognize the new paths/keys will not install.

2) Less choices: defaults to installing Office XP automation components and since only XP or 2000 can be registered at any one time, and I use some tools that require version 2000, I had to manually unregister one and register the other.

3) More stable: hmmm. Is it? How come I got an "Access Violation" when trying to add a new package (having only remove and installed the previously mentioned one)? And how come it doesn't show on TaskManager's Application List and only on Process list? (Yes, you're guessing it right: I had to *forcefully* terminate it! And mind you that I had previously cleaned my PC of BDS 2006 and even manually removed some registry/folder left overs, plus the mandatory reboot, so it was pretty much clean of any leftovers...)
Update: No such error after installing on a "clean" Windows XP + Office 2003 only installation.

4) Even more stable? How come I got *another* different exception after restarting the IDE and trying to load my current project? :( Again, not anymore on a "clean" system.

5) The "shiny brand new MSBUILD": What about some examples instead of simply describing the options? Being a new feature would not hurt to have some examples! Also, the help mentions "pre-build", "pre-link" and "post-build" stages: only the 1st and last are available in Delphi...

[Edit: and a few more...]
6) When making my first build event, I came upon the following, which I consider wrong, behaviour:
- Added a command;
- Made a Build;
- There is a message in the output pane saying something like: "[Exec Error] The command "...." exited with code 1.
- In the post-build events, the option to "cancel build on error" is set to true.
So, how come it considers the build sucessfull?

7) When exploring with the post build events, I managed to get to a point where I was consistently locking the IDE! Had to end-task it. Then, after changing the events it started building, and I was no longer able to reproduce that behavior...

Stay tunned for some positive feedback after the baby's bath... :)

Delphi for Win32 - Part 5 - A new beginning

Well, after I finally prepared my dev machine intentionally without the .NET 2.0 Framework, I was once more ready to install Delphi 2007.

In doing so, I discovered that I had previously used an "incomplete" ISO for the install, hence the (non-problem) I reported of it trying to re-download the files. I'll re-install it again shortly, after restoring my pre-Delphi ghost image just to verify that.
[Edit: Well, I tried it again and found out that it wasn't my fault after all! The current installer requires the files on the folder pointed with the red arrow on one of the images below.]

The install process is divided into 3 parts:
- Detect/Download/Install pre-requisites (.NET 2.0 Framework, SDK and J# Runtime);
- Enter your registration data and make your selections;
- Download/Install the CodeGear related files.

As for the install options, here's what you have available in the Professional edition:


And here's the disk space used by the download and install:

As you can see from this, the install files (cached on the folder pointed to by the arrow), use roughly 1.4 GB. To that, you add approximately 1.5 GB of Microsoft related stuff (.NET 2.0 Framework, SDK, SDK install files, .NET 2.0 help files (part of the SDK but worth mentioning the waste of space when installing a "for Win32" type of development app!).

All in all, of the 2 GB needed (not counting the install files), only less than 700 MB are used by CodeGear: the remaining 1.4 GB is "spent" by Microsoft Runtimes, SDKs and tools.

For those more inclined to go and add all the bytes: the values above are approximations, give or take a couple hundred MB! I'm just too lazy to do all the math properly! :)

One nice thing about the install process: part 3 (the one where it installs CodeGear stuff), only takes around 4 minutes on my machine if you already have the files downloaded! Very fast indeed...

Delphi for Win32 - Part 4 (aka: The Day After)

Well, one day after I finally was able to download and install Delphi 2007 (thanks go to DavidI and Michael Swindell for their help in speeding up the process), I must say that it's not what I'd think it would be!

When waiting for the manual ESD ordering process (involving wire transfers, e-mails back and forth, waiting what seemed like an eternity just because Portugal is "one of those countries" where we can't order CodeGear products online and have that "instant gratification"), I thought that I would be spending my first day with Delphi 2007 exploring all the new features...

I thought, because I didn't! And why? Well, a couple Access Violations on the new IDE even before adding any third-party tool and without having BDS 2006 on my system anymore, made me wonder if Delphi 2007 was indeed that more stable than BDS 2006 which had not crashed on me for so many months that I can't remember when it was the last time!

One such violation was when removing the Office XP automation and installing the Office 2K automation instead as one of the component sets I use requires that version instead (yes, Delphi 2007 is using a "Vista" approach: "We know better than you what you like, so we don't ask you and install what we decide!").

This AV was a bit drastic as it kept poping up and I had to forcefully end-task the IDE.

The other AV was after restarting the IDE and when trying to add some other components, so it may have been those components fault.

So, in order to set things straight, I decided to go back to an old ghost image of my C: drive with only Windows, Office and updates.

I had saved the cache folder where the Delphi installer downloads the files, and made it into an ISO. Mounted that ISO, fired the install, only to find out that it would go download .NET 2.0 Framework: a quick check and, ok, let it go on as I don't have that installed. However, when it started trying to download all the other files it already had on the ISO, I aborted it and instead copied all the remaining files to the folder the install expects them to be in. (Hint for CodeGear: some instructions on how to make this into a DVD would be nice!)

It all went ok and when I ran Delphi 2007 and did the same operation as before it no longer crashed. So, now I was facing the task of re-installing a ton of utilities that I use, from UltraEdit to WinZip and many others, so, instead of doing it, I decided it was time to find a way to make them "install-less" and place them on sub-folders of my D:\Utils so I would save myself some work on my next installs. And so that was my first day with Delphi 2007!

I'm pretty happy with how much leaner my system looks and feels with my Start Menu so much less cluttered (not that I use it anyway!), and above all, my registry not being flooded with tons of useless information. So, at this point, and having gone back to my previous ghost image again to verify that all the utils were in fact working properly on a "clean" image, I'm now about to install Delphi 2007 for the third time. I already took some notes on the install process and some minor (and some not so minor) issues, and that will be the subject of my next post...

Overall, some times bad things come for good and having Delphi 2007 blow up on me at the start made me clean up my dev system, so that's some good out of that!

Delphi for Win32 - Part 3

Houston: the key has landed! :)

Now onto the remaining installation.

Here's what the installer looks like:


And here are the fully expanded installation options for the Professional SKU:

Delphi for Win32 - Worldwide ESD Purchase?

I haven't tested this (other than seeing that the link works), but I received as an answer to my question of whether I could purchase the ESD and download it even from Portugal. Oddly enough, I received an answer that links to the Latin America Borland Shop.

I am already waiting on my already paid ESD from my local distributor but those of you out there stuck without a way to buy the ESD online may want to give it a try.

Here's the link: Delphi for Win32 ESD Worldwide Purchase.
[EDIT] At least one UK user tried and he could not make the purchase from there. Either someone thinks that Portugal is part of Latin America, or I don't see why they sent me that address to make the ESD purchase!]

Please post a comment stating your experience with that if you use it.

Delphi for Win32 - Part 2

Well, while I keep waiting for my Delphi for Win32 code to arrive, what else can I write about?

I can start with a word of warning for "wanna-be" ESD users: make sure your C: partition has plenty room available. And I don't mean a DVD-Size type of space, but at least twice as much!

Actually, I don't yet know, for the reason mentioned above, what exact space is needed, but I did run the installer and allowed it to fetch the pre-reqs (essentially .NET 2.0 SDK, hereafter referred to as simply SDK). That's pretty much all I can do until the code arrives, so I took a look at my C: drive. It was a bit of a shock to see that I had lost 1.6 GB of free space in my C: drive!

Why?

To keep it simple, 600 MB for the SDK install files that the Delphi installer caches under Documents and Settings, 600 MB for another copy of that file that is simply copied inside a "Microsoft Visual Studio 8" folder in My Programs, and the same contents but this time after extraction partly to Program Files and partly to Documents and Settings.

That's a whole lot of space! And I've yet to start downloading Delphi's own setup files! I wonder if I have enough free space on my C: drive to continue the installation.

And, of course, it's also worth mentioning that of those SDK files actually installed, around 400 MB are pretty useless to me and to pretty much every Delphi for Win32 user: they're the .NET documentation files...

Pre and Post-Build automation in Delphi

Abstract: This article describes a simple way to extend the IDE so that Pre-Build and Post-Build tasks can be automated without a single line of code. This works for BDS 2006 and may work (untested) for BDS 2005.

Why Pre or Post-Build?

I’m trying to create my first shareware program in my free time. Using Delphi on my laptop for company work, it was the logical choice to make this project. With that comes adding some security measures and so I chose Armadillo (now SoftwarePassport). The way this protection works is by wrapping the program’s exe or dll which means it has to be done after building the main program. This protective wrapper needs to be in place even for development work, be that to test settings related to the protection itself or simply to avoid a large number of conditional defines to block code out.

For the last few days I’ve been trying to automate the process which involves running a windows application with certain parameters. Because there is not much information on how to successfully accomplish this, I decided to write this article to share the workaround that I found to be very good, at least until Delphi gains a more customizable builder.

The solution

The whole idea works around 2 concepts applied together: using Build Tools and Project Groups.

I’ll describe the process for the Post-Build situation in my particular case, but, by playing around with the build order, this can easily be adapted to Pre-Build too and you can even have several Pre and Post-Build tools being executed.

Step-by-step instructions

Let’s start by opening your project.

Now, right-click on the Project Group and select "Add New Project…".

Any type of project will do, I selected a console application and named it PostBuild, but again, any name will do. You can keep your project the Active one.

Save all that and choose a proper name for the .bdsgroup file.

Now right-click on the PostBuild project in the project explorer and select "Dependencies…": this is one of the most important steps because in here you can say that this project (PostBuild) depends on another one (your main project), so that it will always be built after your main one.

Now for the tool configuration.

In my particular case, I need to run the following command line:

"C:\Program Files\SoftwarePassport\Armadillo.exe" "D:\Dev\My Prog\Prot.arm" /P

So, let’s do 2 things here: add the Prot.arm file to the Post-Build project and create a Build Tool to handle .arm files.

The Build Tools dialog, or more specifically, the "Add…" sub-dialog, could use a bit more explanation in the help file but eventually I got it working as you might have guessed or I would not be writing this article!

The key points in this dialog are:

Title: Anything will do but using a descriptive title always helps

Default Extensions: *.arm (this is for my case for the example command-line above)

Command Line: This is the trickiest of them all, but after you get one working, they’re all easy. The trick here is not to use quotes on the program’s name but instead use the windows SFN (Short File Name). The reason is that, should you need to use quotes to enclose the path of your file, the IDE gets confused with too many quotes.

So, these are the wrong ways of adding that command line above:

C:\Program Files\SoftwarePassport\Armadillo.exe D:\Dev\My Prog\Prot.arm /P

"C:\Program Files\SoftwarePassport\Armadillo.exe" D:\Dev\My Prog\Prot.arm /P

C:\Program Files\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P

"C:\Program Files\SoftwarePassport\Armadillo.exe" "D:\Dev\My Prog\Prot.arm" /P

This last one should work, if it were not for the IDE to be confused with it. So, what does work is this one:

C:\Progra~1\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P

Notice the SFN on the program to be executed, thus leaving the quotes available for use on the file name. Of course, we don’t want this exactly as it is as it would be hard coded. We can use some Macros to make it more generic, so here are the Add Build Tool contents for my case:

Title: ArmProtect

Default Extensions: *.arm

Command Line: C:\Progra~1\SoftwarePassport\Armadillo.exe "$PATH$NAME" /P

Using these Macros is also the reason why I used SFN on the program and not on the filename! In this case, "$PATH$NAME" gets expanded to "D:\Dev\My Prog\Prot.arm".

Don't forget that this tool will only be used on the extensions indicated in this dialog.

You can also, at any point in time, manually run this command by right-clicking any *.arm file on your project and selecting the tool from the menu.

The final step to remember is to Build All Projects (you can give it a keyboard shortcut to make it easier to use and/or put it on your toolbar).

In short:

1 - Add a PostBuild "void" project to your project group;

2 - Right click that project, select Dependencies and make it depend on your main project;

3 - Add the file you want to be processed after building your program to the PostBuild project;

4 - Create a Build Tool to run the proper command-line and associate it with that file’s extension (don't forget about using SFN for the program name);

5 - Always load the .bdsgroup instead of the .bdsproj and use Project -> Build All Projects whenever you want the Pre/Post-Build to work.

Final Notes

This process was tested with BDS 2006 and should probably work with BDS 2005 too but I haven’t tested in that IDE.

You may need to exit and re-open the IDE for it to acknowledge changes to Build Tools, especially when you just added a new one.

Adding a Pre-Build is also easy to achieve playing with the project’s dependencies: you will need to make your main project dependent on the PreBuild one.

If you need to add some step that does not depend on any type of file, simply make up some extension (use 4 or more characters to avoid conflicts with existing extensions) and create a void file of that extension to associate with the Build Tool, for instance, "nothing.step1".

If you want to customize the Build Current Project key to perform Build All Projects instead, take a look at the free GExperts Add-In.

I hope that this information is as valuable to those reading this as it is for me. I've yet to try out the new MSBUILD, so until then, this workaround works like a charm.

Delphi for Win32 - Part 1

In these multi-part posts about the newly released Delphi for Win32, I'll be blogging about my ordering, installation and usage experiences.

Part 1 (this one you're reading), is about the new ESD version that is available from CodeGear starting with Delphi for Win32.

So, now you have an ESD (Electronic Software Delivery?), meaning that, in theory and using CodeGear's own words, you get "Instant gratification".

I'm a big fan of ESDs: ever since there were internet purchases I've been doing them and all over these years, I've easily made over 100 such purchases. The big advantage of an ESD is to allow you to skip all that lengthy process of duplicating the CDs/DVDs and distributing them all over the globe, so, in theory, it's a nice idea.

Now let me talk a bit about CodeGear's first ESD: Delphi for Win32.

Having attended the CodeRage virtual conference last week, I was caught by surprise on Friday, the closing day, that CodeGear had started to ship Delphi for Win32. So, time to grab my credit card and go check their site... Hmm... There's no such thing as Portugal on their listing, so I'll have to try Spain instead.

Cuting a looong story short, let me just say that I did fight for a few hours trying to find a CodeGear online shop/partner/whatever that would allow me to have that "instant gratification". It turns out that I was expecting too much for two main reasons:

1) In these days of e-commerce and EEC, they block sales from their resellers to other countries, maybe it's something from Borland age and has to do with some business areas but still incomprehensible in these global days we're living;

2) The other reason I was expecting too much was because it wasn't actually official until next Monday, so, Friday was not the release date as I initially thought.

That much I learned after "bugging" DavidI and Michael Swindell.
Having learned that I waited until next Monday to be contacted, as promised by CodeGear. And, in fact, I was: first by a Portuguese retailer, then by a Spanish distributor telling me they had instructed that Portuguese retailer to get in touch with me.

And so they did: after answering their initial request as to what product I was interested in, I waited a few more hours. Late, near business day end, they contacted me again with pricing (there was an issue with using a special CodeRage attendant discount), and, after they told me how to buy the "ESD", I made a wire transfer and mailed them back. I had been told that, from the moment I placed my order, it would have taken 12 hours to receive the "ESD" (gosh: internet is sooo slow!), but 16 hours are gone now and still no code in my mail... :(

[EDIT: It turns out, from their answer just now, that it's 12 "business hours"; considering that they sent me the wire transfer data at the end of yesterday's business day, and even though I made the transfer right away and with 40 minutes to spare, they only picked up my order process today! So, if it's 12 "business hours", this means that ESD for Portugal = 3 days from start to finish... And I thought the year was 2007!!]

Meanwhile, bugging Michael a bit more, I managed to start the Download/Install procedure: I'm yet to get past that stage where I have to enter the yet to be received key, but at least I've now allowed the ESD installer to download the 600 MB of pre-reqs. (More on that on my next post!)

Final notes:

1) For their first ESD experience, I've read that it isn't going that bad, at least in "Civilized" countries for which they have online stores and allow that "instant gratification"; there were a few issues over the weekend but since it was not even supposed to be working 'til Monday, that's no big deal.

2) They *do* need to sort things out for the remaining countries: buying an ESD by using FAX order forms and/or wire transfers is not the way ESDs were meant to be! My suggestion: until local retailers are capable of providing that "instant gratification" experience, allow other retailers to at least sell the ESDs for those countries. If the local retailers don't want to loose on those customers, then they will catch up.

Unless they sort this out, some developers will be 1st class customers with "instant gratification", while others will have to wait, and wait, and wait...

3) CodeGear support was impressive. They have gone to all the lengths to have the right people talk to me and allow me to place the order. It's a bit slow process in Portugal, unfortunately, but I hope that sometime later today I'll be completing the install.

So, stay tuned for more comments on Delphi for Win32...

WriteLn( 'Hello World!');

Welcome to my first blog post in Blogger.

In here, I plan to be posting my thoughts about Delphi in general and Delphi for Win32 in particular. I'll start with a series of posts telling you about my current Delphi for Win32 installation and usage experience.

So, stay tunned.