Paths, Seattle and Berlin

By | May 8, 2016

Paths

If you are one of those developers out there who have multiple copies of RAD Studio on your machine, especially if you trying to maintain Open Tools API projects for different IDEs you will most likely have come across the problem of broken paths. The most severe case being that various Windows components stop working. This isn’t a problem with the RD Studio installers but a limitation of Windows (yes, even today Windows still has some nonsensical limits). Your system path should have %systemroot% and %systemroot%\System32 in there, preferably at the start of the path. With out these Windows has problems. It’s unclear what the exact limit to the path is (system and user combined) but I’ve seen reference to 2048 characters. Each modern version of RAD Studio installs 4 paths which eat into this a great deal.

This eventually happen to me after trying to re-install Delphi 5 and C++ Builder 5 on my machine. It didn’t take long to work out what had happen but I found editing the path through the Windows interface very tedious so I decided to write a small application to do this for me (see Path Editor). This also provided me with an opportunity to get my head back into C++ Builder. I’ve never done a lot of C++ in the past mainly because I’ve never chosen to do a whole project in C++ Builder. During the process of creating the application I decided to do a number of things that I take for granted in Delphi but didn’t know how to do in C++ Builder. One of those was to create my own event handlers for my frame object which contains the logic for editing paths (see below).

typedef void __fastcall (__closure *TUpdatePathProc)(TObject *Sender, String strPath); // Event Method Signature
  __property TUpdatePathProc OnUpdate = {read = FUpdatePathProc, write = FUpdatePathProc}; // Event Declaration

I started using this style of writing code in an attempt to decouple modules / classes of code from having to know about other lumps of code. It works well and makes it easier to reuse the code elsewhere. I also found out how easy it is to have the IDE insert a frame you’ve built in your project into another form. Don’t ask me why I have never found this before since its been around since Delphi 5 but I like to think I can learn something new every day.

Its taken a little time to get used to the different ways in which C++ Builder does thing and for me I do find it slower to get done what I want (not much though). I don’t know whether this is inexperience or C++ Builder’s way of doing thing but I intended to keep this knowledge going and hopefully (eventually) I will actually get to the point of writing something about the Open Tools API for C++ Builder (current work so far compiles, load into the IDE but doesn’t do anything, i.e. the Register() procedure doesn’t seem to get called).

Seattle and Berlin

I updated to Seattle about 2 months ago and have been very impressed with the performance and stability of the IDE. My previous IDE, Delphi XE7 seems to lock up after a few hours of coding, compiling and debugging. It didn’t show an error dialogue, its internal one or generate one with EurekaLog, so I never got to the bottom of this. I found that if I removed plug-ins (including my own) it lasted longer but still froze eventually. I’ve not experience this with Seattle or Berlin although I’ve only done OTA projects in Berlin at the moment as I’m waiting for a couple of updates for CodeSite, EurekaLog and JediVCS before I can fully move over.

I’ve found the process for updating my OTA projects generally very smooth for Seattle and Berlin. They load projects quicker, load quicker and I only think I’ve had 2 issues along the way but those could have been related to very old C++ Builder projects I was trying to update.