Where NOT to put your Delphi components

This is just a bit of an observation of things I’ve noticed in the past month or so.

As an MVP I often have several copies of Delphi, both release and beta, installed on multiple machines. I also have a burgeoning amount of components on those machines; either ones I use or ones I want to write about or ones I’ve been sent by the vendors for me to comment on and provide feedback.

I know I’m not totally typical but I’m also a professional software developer writing code day in and day out using Delphi and using the component-based ecosystem to its full advantage.

So, in the style of a battle-hardened action movie character: “I’ve seen things… things you wouldn’t believe“.

It’s common for some Delphi component suppliers to install things into your documents folder. I have no problem with that and it’s quite often just documentation which makes a lot of sense.

However, I’ve noticed a few components, for whatever reason, actually installing the source code of the components into the “My Documents” folder. I’m not sure if it has been because of a default I might have picked eons ago or a general default but right now, if you use OneDrive or Windows 10 it’s a Very Bad Thing. Windows 10 changed quite a lot of things over the years, drip-feeding new features bit by bit into the desktop experience. That’s a great idea and helps ease people into a forward direction without overwhelming them with too many changes all at once.

However, one of those more recent features is that, for Microsoft Office users at least, many things are actively being stored on Microsoft’s OneDrive cloud storage solution. In latter versions of Windows 10 this means that files you copy to the “My Documents” folder are then synced to ‘the cloud’ and become available on any of your other machines.

Except they’re not really there. There is a file system ‘stub’ entry and when you look at those files in Explorer you’ll see a little ‘cloud’ icon:

The cloud means that the file is not physically present on your machine.

That’s when the trouble starts.

If you install a set of Delphi components and the destination is anywhere under one of the ‘special’ Windows folders such as “My Documents” or “Desktop” (seriously I have seen a Delphi developer doing that – don’t do that) then any of your other PCs which are running Windows 10 and are signed in using the same Microsoft account will ‘magically’ get those component folders appear on their machine in the same places… except those files aren’t really there.

When you go to compile a project on your other machine – the one without the actual files but with those cloud icons – the whole process will either fail or go very slowly – and I mean like MINUTES slowly. The reason it goes so slow is that Windows actually creates a deliberate pause accessing the virtual/cloud files while it syncs with OneDrive and downloads them for real onto your PC. Even on a machine with a 1GB fiber connection like mine this is still relatively slow – and in the case of a bigger library it’s going to take quite some time.

Then there’s an even worse problem. Let’s say you now decide to uninstall the components from that second synced machine. The uninstall removes all the source code (as it should) and any BPLs and so on. Now you install a later version of the component set, once again into one of the OneDrive synced folders. When you swap back to your original machine OneDrive starts to sync the changes… and disaster unfolds. You start to get mismatched source and BPLs along with Delphi project and DFM files which are from the later version of the components on your secondary machine.

You’ll also find that – at least currently – OneDrive will spend a VERY long time trying to sync all the file changes between the two machines. You will also get warnings from OneDrive that you “recently deleted a large number of files” and asking if you want to clean out the trash folder with no indication of whether or not this is a good or bad thing. Spoiler alert: do it. 😉

If you have more than one PC and are using OneDrive and you have one or more machines going more slowly than you expect then this could well be what appears to be a problem with OneDrive at the moment; never-ending or very slow synchronizing of files. On a machine which I found to have this problem I temporarily disabled the OneDrive sync and suddenly the machine was back to normal speed.

Also, for any component developers reading this: don’t store things in the program files folders, especially source code and examples. Increasingly these folders are heavily restricted and in many customer configurations they are virtualized. %PROGRAMDATA% and %APPDATA% (depending on your use case) is the correct place for all of that. You can read more here: What Is the ProgramData Folder in Windows? (howtogeek.com)

If you store your samples/demos in the program files folders your users will get error messages trying to run the projects since by default the folders are not writable by mere mortals.

To return to “where to store your components” – I’d suggest you create a folder called "\comps\" and use that as the target destination when installing new components from vendors. This has a couple of advantages –

  • If you have more than one machine all your components will be in the same place rather than program files (86)\name_of_vendor or program files\name_of_vendor
  • It will not get synced by OneDrive by default and you avoid the problems I described above.
  • The path is SHORT which is currently quite significant for RAD Studio which uses the Windows PATH environment variable and you’ve probably seen by now a warning stating the maximum path length is close to being reached.

Of course, none of this may affect you. Perhaps you don’t knowingly use OneDrive (don’t get too complacent, Microsoft are pushing OneDrive and cloud storage hard) or maybe you only use one PC or already store your components in an alternate folder. All good.

But if not then maybe this post might save you some of the grief I’ve experienced in the past few months.

UPDATE: A small update to this – this applies to ANY component library good, bad or ugly – and some people have suggested that their copy of OneDrive doesn’t sync documents folders automatically although I have checked this on a collection of machines both in the UK and US and it definitely affected all of them. A quick Google search shows it to be a common problem too: https://www.google.com/search?q=onedrive+constantly+processing+changes

I’m definitely NOT calling out any component vendors and saying this is their fault but what I am saying is, based on my experience, putting stuff in the documents folder when it is synchronized to the OneDrive cloud can be a major problem; it certainly was for me and even this morning a couple of days after I originally wrote this article I had the problem occur again with a component library and had to manually stop things syncing and delete files to overcome it.

Feel free to contact me directly if you think I’m wrong – my details are public; go for it!

I’m kind of crushed that people thought I was being negative about Delphi and particularly about some components – have you not all been paying attention? 😵

7 thoughts on “Where NOT to put your Delphi components

    1. Hi Ian,
      Thanks for that. I’m starting to move components over to the new location.
      Are there any tools to make it easier to “reload” all components with changing
      the local path and installing when a new version of Delphi is released or if there
      is a need to “reload” the OS? This has been a big pain for me in the past and
      now in my “new mission” to reload components.

      Thanks,
      Charlie

      1. As long as the Delphi ‘major’ version is the same then just make sure not to select “yes” on the checkbox the installer shows which says “do you want to remove all the previous version’s registry entries?” You almost certainly want to KEEP those registry entries and, if you do, you will find all your components and any IDE add-ons still there and working. By major version I mean 10.4 –> 10.41 –> 10.42 (when it comes out). When 10.5 is released later this year it will not be ‘binary compatible’ with 10.4x and that’s where the fun begins. I usually use the Migrationtool to absorb any settings I feel will be appropriate for the new version.

        Migration tool location

        The GetIt dependencies checkboxes in projects can be useful but, yes, overall I think there could be some improvements in making the whole migration process a lot less pain free – I seem to spend a long time staring at component installation screens whenever a new major release comes out!

  1. This is a practice I have designed myself since I use the JCL/JVCL. Having all that stuff below your documents/OneDrive consumes a lot of resources.

    I tend to avoid the use of the My…. as they escape my control when I need to do backups. All my “valuable” files are in a subst’ed DiskD folder which I backup regularly. Components are aside as they do not need backups.

    I had a folder called Components but now I add the name of the version as I tend to have mutliple versions of code which are using different versions of Delphi.

    The use of Documents by Getit is not my favourite, I will for sure adapt the setting you did propose.

    Thanks.

    1. Yes I think the principal idea of OneDrive automatic backup is excellent but there’s something not quite right with the way it seems to work across devices and when Delphi components get stored and then synced across devices that’s when the trouble really seems to start.

Leave a Reply

Your email address will not be published. Required fields are marked *