I received an email today from a person interested in my opinion about Delphi 2007 and CodeGear. In his email he said he felt the Delphi 2007 release is not going as planned. He wasn’t sure if that was because the software sucks, support sucks, or what.
I know experience and opinions can vary person to person, but I think Delphi 2007 rocks and I feel the CodeGear team is doing an amazing job despite a hiccup here and there. And to show more love towards CodeGear and Delphi 2007, here is my reply to the person’s email:
<div class="quote">
I personally think CodeGear’s Delphi 2007 is one of the best releases of Delphi in years. I use the product on a daily basis and I have not experienced any major problems. This latest release makes me excited to use Delphi again.
The only serious problem I encountered was the ordering process but the problems were the fault of Digital River, not CodeGear or Delphi 2007. The CodeGear staff responded quickly to the email I sent informing them of the problems. Not only that, Loreen Fornshell of CodeGear went above and beyond to assist in correcting the problems caused by Digital River.
There is still room for improvement with Delphi. For example, the help system can use a bit more work. But this initial offering from the newly formed CodeGear is not only rock solid (in my opinion) but shows that CodeGear is heading in the right direction.
</div>
Note: It occurs to me as I type this blog entry that the person might be referring to Delphi for PHP. I admit I do not share the same love towards Delphi for PHP as I do for Delphi 2007, but it is after all a version 1.0 product. Visual Studio 2002 and .NET 1.0 wasn’t that great either.
SMTP Diagnostics 1.7 has been released and is available for download. Read here for more information.
I have talked about White Peak Software being a product company for the last couple of years, but the transition from services to products has been challenging. I’m working on a new email program call Vertigo but progress has been slow for various reasons. I learned trying to get a product like Vertigo out the door at single person software company is a huge challenge especially when you rely on services work to bootstrap any R&D; work.
What I need is a different approach, so 8 weeks ago I came up with a set of short term goals to start building momentum towards being a product company. Tomorrow is the last day of the 8 weeks and I’m happy to say I reached my goals as of today. It hasn’t been easy especially over the last couple of weeks which has had me working 14 hour days, but momentum is finally starting to build.
Over the last 8 weeks I released an update to SMTP Diagnostics and published a new product called Killink CSV. I have also made numerous improvements to the White Peak Software web sites including a fully integrated store front. More work is needed but things are off to a good start.
My next challenge is to sustain and build on top of the momentum started over the past 8 weeks. This means a new set of goals for the next 8 weeks. The new goals include:
* At least 2 product releases
* Sell at least 20 units of my products
Key to the next 8 weeks is selling 20 units. This means not only getting updates to Killink CSV out the door but making improvements on the marketing side. Currently, my plans include a press release campaign and Google AdWords. I also plan to do a better job monitoring conversion rates and web site traffic, something I have ignored over the last year and a half.
My motivation level is high and will only get higher as sales increase. But even with a high level of motivation I must do a better job managing my time during the next 8 weeks. I’ve been working 14 days recently and it’s starting to wear on me…and on my wife too.
White Peak Software has a set of support email accounts. Each time an email is received it is logged to a tracking database and internal notification emails are sent out. In addition to responding to incoming email I review email messages marked as spam each day.
I noticed today the number of spam messages received had dropped to only 5. This seemed odd but a new grey listing anti-spam measure was also implemented this week on the mail server. I thought it was too good to be true that 99% of spam messages received were being filtered by the mail server. After all the mail server is configured to mark most spams not deleted them for fear of fault positives.
As it turns out the reduction in new spam messages was not the result of improved filtering but a problem with the tracking system. The support mail accounts have been overloaded the last 48 hours and the tracking system has been slow to catch up. The problem has been fixed and the queued messages are now being processed.
If it had not been for the reduced spam count the problem might have gone undetected for a longer period of time. For once spam proved to be useful.
I was so swamped yesterday that I forgot to blog about the latest release of Killink CSV. Killink CSV 1.0 is available for download and purchase. You can read the official announcement here.
I posted a new version of the Connection Tool for SQL Server. This free tool provides an easy way to test and build connection strings for SQL Server databases. This latest version has improved support for Windows 98/ME and Windows Vista.
One unfortunate side effect with this release is you must delete the ConnectionToolForSQLServer.exe.config file if you used the previous version. This file is found in the same directory as the ConnectionToolForSQLServer.exe program file. If you don’t you will get an error message similar to this:
<div class="quote">
ConnectionToolForSQlServer.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
</div>
I explain the reason for this here.
I learned a valuable lesson today about naming configuration files for my programs. When I started building.NET applications I followed the .NET convention for naming program configuration files: MyProgram.exe.config
These days I write less .NET applications and more native Windows applications using Delphi. I continue using the .NET naming convention for configuration files for all my programs even native Windows applications. This hasn’t been a problem until today.
Today I embedded a manifest into a program and when I ran the program I got the following error message:
<div class="quote">
C:\MyProgram.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
</div>
Without the manifest the program ran fine, but the program failed each time the manifest was included. I first thought a problem was with the manifest. I review the manifest over, and over, and over again. I even used a manifest from another application that does not have the problem. After banging my head on the wall for a couple of hours I found the source of the problem, and it wasn’t the manifest at all.
Like all my programs, this particular program creates a configuration file using the .NET naming convention MyProgram.exe.config. But in this one case the configuration file is stored in the same directory as the program file, and here in lies the problem.
Apparently Windows XP, and I assume Vista as well, expects the program configuration file to be based on some specific config file schema when the manifest is embedded in the program file even if the program is a native Windows program. I knew this to be true with .NET applications but I didn’t realize the same is true for native Windows applications.
I have not spent time figuring out the expected schema. I suspect it is the .NET config file schema, but I now follow a new naming convention. I do not name my config files MyProgram.exe.config any more. Instead I use MyProgram.config, which does not have any negative side effects when stored in the same directory as the program file.
Update: If you want to use the .NET config file naming convention for your native Windows application, your .config file must be an XML, and the root element must be . Other root elements might be allowed but I know works.
Yesterday was a 16 hour work day for me. It was a long day but a good end to a long, busy week. However I made one last minute mistake last night. I posted the new release of Killink CSV but I forgot to update the download page with links to the new download files. My apologies to anyone who tried downloading the program in the last 12 hours.
I updated the download page this morning, so all is well now.
Whew, it’s been a long, busy week.
I have been hammering away at various performance issues with Killink CSV and I’m happy to announce a stable build is now available for download. This is Release Candidate 1. Assuming no more show stoppers the final release of Killink CSV should be posted in a few days.
I’ll try to find time this weekend to blog about some of the performance improvements made in Killink CSV. One aspect I find exciting is the use of a custom dataset that allows a single copy of the delimited data to exists in memory and is used to feed data to the print module. But more on that later.
I’ve also been busy this week cleaning up the White Peak Software web site and the Killink CSV web site. The SMTP Diagnostics web site will be updated soon. Also look for a new release of SMTP Diagnostics coming soon with better Windows Vista support.
And if you haven’t seen it yet check out the new White Peak Software Store. The new store front is fully integrated with the White Peak Software web site giving the customer a more seamless shopping experience.
As I said, it has been a long, busy week.
Yesterday I had a need to install PowerPoint 2007. Typically I install something like this in a virtual machine to avoid problems with other applications but yesterday I was in a rush so I installed PowerPoint 2007 in my “production” VM. The Office 2007 installation gave me the option to keep my Office 2003 applications and install only PowerPoint 2007. “Groovy!” I thought. Well, it turns out not to be so groovy.
After installing PowerPoint 2007 and doing what I needed to do, I launched Outlook 2003. As Outlook 2003 was loading the Office 2007 installer popped up and attempted to install something. I cancel the installer and Outlook 2003 finally loads. I checked my mail, read a few messages, and clicked Reply to author a response to a new message. Here’s where the problem started.
I have Outlook configured to use Word as the editor for messages. When I tried to reply to a message Outlook locked up. Not only did the application lock up but the entire operating system locked up. I had no choice but to power off.
Rebooting didn’t help either. Outlook 2003 did not properly load, and I had a new problem. Microsoft’s automatic update was now maxing out the CPU. To regain control over the machine I killed the automatic update process.
After dealing with this mess I believe I found a work around. After installing PowerPoint 2007 and before launch Outlook 2003, launch Word 2003. If your experience is similar to mine you will notice Word 2003 loads without the XP theme. After about 30 seconds Word 2003’s UI switches to the XP theme. It is after this point that Outlook 2003 is once again able to use Word 2003 as its editor.
I can’t guarantee this will work for you but it did work for me. I’m now able to use Outlook 2003 once again.
The only problem that remains is the automatic update for Windows. It still maxes out the CPU and the process must be manually killed. I can handle doing this until I have time to re-build a new “production” VM.
Update: I found this wordaround to the maxed out CPU problem.