Idle Musings of a Delphi Junkie

This will be my last post on this blog, as I've moved my meager blogging exploits to a new home. Feel free to mosey on over there for a full explanation. :-)

As part of the Highlander Beta Blogging initiative, I have been given permission from CodeGear to demonstrate features and functionality of the up and coming CodeGear RAD Studio product.

As CodeGear are also currently running a video competition, I thought I'd use this unfair advantage to enter :-)

The following two videos (they were one, but had to be split in order to comply with YouTubes 10 minute limit) demonstrate a simple Master Detail application created in ECO using VCL.NET as the presentation framework. In the first video, the data is persisted to an XML file.



The second video extends upon this to change the persistence to write the data in a BlackfishSQL database.



I strongly encourage all readers/viewers to favour these videos. I can't guarantee any fame or fortune to come your way, but I will be sure to have a beer in your honour. Heck, if you ever get over to New Zealand, I may even be convinced to shout you one. :-)

UPDATE: I have uploaded the original video to CodeGear Developer Network. I would recommend watching this one rather than the two I submitted to YouTube. The content is the same, but there is no loss in resolution. Feel free to still vote for my YouTube submissions though. :-)

Labels: BlackfishSQL, CodeGear, Delphi, Development, ECO, MDA, programming

• If you're feeling thirsty, Apple juice is pretty good for you.


• Those wacky Trojans are at it again.

I've decided to take the challenge issued by Steve Trefethan, and have extended his excellent list with my take:

• Learn to populate your user interface from the database without using TDataSet/TDataSource


• Learn to leverage the power of the Refactoring menu


• Learn how to write and leverage effective unit tests


• Write a Delphi for .NET application. You won't get cooties, I promise


• Write an ECO application


• Learn how to leverage interfaces to add runtime discoverable behaviours to classes


• Write an article and submit it to Codegear Developer Network


• Learn another language. You will become a stronger Delphi developer for your efforts


• Point your local school or college to the Turbo Explorer suite of products. For bonus points, offer to teach a Delphi programming course


• Unsubscribe from borland.public.delphi.non-technical

A few weeks back, my boss showed me a technique he uses when inserting a record into a FireBird table, which caters for the scenario that the record may already be there and therefore shouldn't be inserted. It was one of those simple yet elegant solutions, and I've been meaning to share it here. Well, I'm waiting for a data import process to finish, so I thought I'd take the time to finally do this.

The technique revolves around turning the concept of a left join on its head and using it to check for failure (i.e a null field value). Here is an example of what I'm talking about :-

insert into tax_category(category_description, tax_rate)
select 'GST', '12.5' from rdb$database
left join tax_category t
on t.category_description = 'GST'
where t.category_id is null;

The above snippet will attempt to insert a record into the tax_category table using a set of hard-coded values, but because of the left join and where clause, the recordset being used for the insert will be empty if the join finds an existing record in the table.

Labels: Database, Delphi, FireBird, Interbase, programming, SQL

I have been given permission from CodeGear to blog about some of the new features in the soon to be released Delphi 2007 for Win32, code named Spacely. It seemed like as good an excuse as any to wake this normally sleepy blog from its usual slumber.

One of the major complaints with Delphi 2006 was the quality of the online help shipped with the product. I know personally that I find locating the information I require in the D2006 help to be a lot more cumbersome than in Delphi versions 7 and below.

For instance, when looking up the help for a particular class, often related symbols are listed in the help but with no hyperlink, forcing you to search for that symbol individually as you peruse down the chain of responsibility for the class. And another pet peeve is how all symbols for a class are listed strictly in alphabetical order, rather than also being limited by scope.

Thankfully, CodeGear have acknowledged this as a major issue, and have been taking significant steps to improve the situation. I am glad to say that the D2007 help has improved tremendously in this regard. As a little teaser, below I've attached screenshots showing the summary for the TCollectionItem class, along with details of all members. As a comparison, I've also included a screenshot of the same information from the D2006 help. For the benefit for readers who have not seen the D2006 help, these screenshots preceed the D2007 ones in each example (and are not covered in a big Beta version disclaimer :-)). A larger version of each of the below screenshots can be shown by clicking on them.





You'll note in the above screenshot that the class heirarchy is rendered in a graphical fashion. It is also important to note that each of the individual boxes representing a class in the inheritance tree is hyperlinked to the help summary for the class being shown.





In the above shot, you can clearly see that the members for the TCollectionItem class are grouped by visibility level. These sections can also be collapsed and expanded, as evidenced by the public methods section being collapsed in the screenshot. There is also additional information shown about each symbol in the class, such as whether it is a virtual method.

Now, I don't expect a 100% perfect help system in their first attempt to resolve all the issues in the previous version, but it certainly seems that significant strides have been made in this area. So it seems the Little River Band were right, and Help is on its way :-)

I was reminded once again this week of the usefulness of a tool I initially discovered a while ago when resolving a bug with CodeCentral downloading submissions in IE7. This handy little utility called Fiddler is an HTTP proxy which allows you to intercept and log all HTTP traffic between clients and servers. It also allows you to place breakpoints so request and response packets can be manually altered.

This week I've been working on developing a REST web service client. I can't make the assumption that a timed out transmission wasn't actually received and processed at the server, so I needed to ensure I gracefully handled any timeouts when posting requests. The thing that made simulating this particular condition interesting was that I wanted certain requests to succeed and others to fail. And because I don't have control over the server, this would normally require writing my own dummy server or proxy app so I could simulate this behavior. But by using Fiddler, I was able easily to intercept all traffic to the server and prevent certain packets from getting through, which would then have the desired effect of a timeout being raised for those particular HTTP post operations.

While this may be vastly under utilizing the power of Fiddler, it certainly served as a timely reminder to me how useful this tool is when developing HTTP based applications.