Delphi2005 and tlibimp

It appears the new type library import wizard is broken (or inconsistent). If you want to ensure you don't get component wrappers generated for a particular type library you should open up a console (dos box) and execute the following command "..\bin\tlibimp.exe -Ha- -Hr- -Hs- msxml4.dll" after having changed in the "\bds\3.0\imports\" folder. Change the library name and path(s) as required for your case.

As usual, you can edit the uses clause to remove the extra units that are automatically inserted (normally leaving only Windows and ActiveX are sufficient). This can be a benefit depending on your intended use as the compiled binary will have less dependencies and you can have a significant benefit on your binaries size.

Delphi.NET and the Compact Framework

Danny has provided an update on Delphi support of the Compact Framework. It all sounds very promising but...

For myself, and I would guess many others, we are being faced with a new challenge where PDA/Phone devices are much more prevalent to our solutions. In the past I have been very blessed by the hard work of the Delphi team to provide not only a top of the line visual tool for both client and server components but a complete tool that can be used for absolutely every need no matter how low level (only missing out on driver development but thank the gods I haven't had to do that). I enjoyed being able to easily contrast Delphi against VB, C++, and Java. If you wanted fast development, good maintainability, and robust software you choose Delphi. When it came to micro devices, in days gone past, it was easy to explain why alternate tools were required for Windows and Palm devices however with the broad availability of J2ME and .NET CF it is becoming much more difficult to continue to suggest that two skillsets are required to develop and deploy against these devices.

Without even marginal support for the Compact Framework Borland has, not intentionally, reduced Delphi to the position VB once owned for Win32 development. While VB has been available on micro devices for some time prior to CF.NET it was really a weak contender with extremely limited capabilities to actually use the platform. Using and supporting CF.NET gives Borland a clear chance to provide a viable alternative for long standing Delphi fans that are not greatly interested in a full scale switch over to C# or Java. If someone wants to suggest we don't have to consider the benefits of having only a single language their developers can support then they simply don't understand the cost savings and risk mitigation that are achieved when everyone in a dev shop can be tasked with code changes. The days when it was acceptable to keep a couple resources around for the C++/Java bits done on compact devices are gone.

What I am looking for from Borland is the ability to create and deploy applications to these devices. What I am not looking for are things like VCL.NET, advanced debugging support, and designer support. I would certainly take those features if they were offered but they are definitely not high on my list of needs. Having done development for Palm, Embedded VB, Embedded C++, and some recent CF.NET work I know that the most important capability I value is quite simply the ability to make it work on the platform.

Application servers, web clients, and full rich clients are still my bread and butter. Micro devices, while increasing in importance, still remains the candy to be offered as value adds to those primary services. The only thing I need right now is being able to target the CF.NET platform in if the methods are primitive.

So, if you want Borland to let you in the playground, rather than watching from outside the fence then head over to Danny's most recent blog on CF and let him know the things that you require most and that we need it sooner rather than later.

Google Maps and Google Code

Google has recently announced and released two very cool new offerings. Google Maps has got to be one of the coolest web/script only applications that offers that particular type of functionality. It is incredibly fast and I definitely enjoyed having my region there in all it's glory. You definitely have to check it out. It is still just a beta but I really hope to see the ability to link to it for directions (which is pulls off flawlessly) and perhaps some developer API's. I know from past experience with ESRI this web based interface seems like a real charm.

Along with the maps they have yet another site, Google Code that has some decent code and API documentation. Since the old BLogger API appears to be malfunctioning a bit I was glad to see the Atom API documentation listed there. I need to update my blogging tool to use it so I can get rid of those pesky error messages.

Delphi, Uses, IFilter, and MSN Desktop Search

It has been ages since I have posted anything and I have not gotten around to posting on some of the items I had in the queue but that will happen eventually.

I am sure many people are aware that the desktop search choices are coming out fast and furious. I have about 500K files/items on my local computer and I am definitely in the habit of misplacing a particular file often enough.

I hadn't bothered with the first Google Desktop Search (GDS) as it would not index content outside of a pretty refined set of file types. The recently released version corrects that problem and is a pretty small download. It does a much better job in what it will index and is extensible with some programming (using IDispatch based interfaces, tsk tsk). I am sure it will be a decent tool but I don't really have a high degree of trust in letting it into my Outlook data just yet. I have it installed on a Virtual PC to give it a test and play around with it. Since I use google as my mainstay web search it isn't a stretch to doing it on my desktop as well.

I have had the MSN Desktop Search beta installed since it was released. I simply couldn't pass on an opportunity to quickly search through my Outlook e-mail. The packrat in me has led me to having an archive policy set to six months and over the years I am up around 3GB of archived e-mail. Searching into those archives in a reasonable fashion is a dream come true. MSN Desktop Search does it both quickly and reliably. Searches against Outlook are incredibly fast and it hasn't let me down on a single search yet.

A secondary, although more often used, search need is grepping through the volumes of the source code (predominately Delphi). Typically I have stuck with the dos based grep and/or the Delphi editor supplied version. This works for many cases but the search speed certainly doesn't compare to what you find from either of the two search engines I have tried thus far. For code and html documentation libaries you simply can't lose by installing one of these search engines.

But... I want more. The MSN Desktop Search takes advantage of the IFilter interface that was designed for other Microsoft Search technologies such as Index Server and SharePoint (I am not convinced that the new search is anything other then a new face on an already pre-existing and robust technology). Using the IFilter interface permits you to use any existing filters that may exist such as the PDF filter that is linked on the beta download page. But, more importantly, it allows the addition of new filters that you can develop yourself for custom formats or specialized needs.

This was my first step into filter development so I started with something simple that would be of potential benefit to myself. I have many shared modules between many projects so a change in a particular module can have far reaching impacts. These projects can be old mothballed projects, up and coming work, and large efforts with many external dependencies that I need to watch for. Before, or more likely while, making some changes it is definitely an asset to initiate a light impact analysis to see any dependencies that should be watched for. So, to this end I figured a uses filter extension would be just up my alley. Since it involves parsing the Delphi source it also permits extending the search patterns to include searching for where classes and functions are used versus defined. Part of this is about just having some fun doing it versus building up an impact tool... good for helping with first guess estimates.

The uses filter parses Delphi source files, establishing the list of used units. Additional custom properties are added with the list as well as setting the standard keywords property with that list. This means I can execute a search such as "keywords:unit_name" and I am then presented with a list of Delphi source files that use that particular unit. This helps keep the search results short and usable since the words are not scanned in every e-mail, document, and text file floating around your local machine.

The picture belows shows a search that shows modules using two units at the same time. You will note that the named units are in the keywords properties (this also means we don't find units where the unit may have been historically used and may have been commented out, etc).



Delphi, of course, is the tool I used. After stumbling around for a while I ended up building up a filter interface file with the relevant declarations for constants, types, and interfaces. I then created a new ActiveX project and created the basic framework code with support for the necessary interfaces and stub implementations. Be an appropriately lazy developer, I decided to implement the filter as an extension/aggregate of the stock text filter the desktop search was using and simply tag my extra bits on afterwards. This means I wasn't losing any basic text search capabilities either. To this end, I was able to get the filter up and running pretty quickly with the help of the filter test tools from the MS SDK. Using Martin Waldenburg's excellent mwPasLex source code made accurately extracting the uses from the source files a breeze. After setting a few registry entries (see the MSDN IFilter for details) I was up and running with a working copy pretty quickly aside from the long re-index times required for good testing. The moral of that story is don't test on a machine with 500K files; thank heavens for virtual PC.


I am still testing and tweaking the code otherwise I would make it available on the site. If you happen to be interested in having the code (for any purpose) just leave a comment with a suitably spam-proofed e-mail and I will forward along the current version. I want to figure out how I can get the desktop search to respect my new properties for both display and searching. I didn't want to use the keywords property but all my initial attempts to get the search engine to use my "uses:" prefix simply failed. If someone knows how that works (not on SharePoint or Index Server) I would be quite interested since I think is where the real power resides.