I know a fair few people in the Delphi world and I’m fortunate to call several of them my friends. It’s nice to hang out online with fellow like-minded developers and it’s doubly-handy since we often swap ideas about tricky stuff we’re stuck on. Generally one of us has something useful to contribute which can help unstick the stuck code. We’re not turning up at each other’s doorsteps with cakes and cookies but we’re techies anyway so that sort of stuff would be odd even without a global pandemic.

We hang out in a group where it’s a safe space to chat about things that we might not always want to waft into the air at a webinar or website. Nothing too dramatic, but it’s good to have somewhere like that. I’ve mentioned people like Holger Flick before since we often crop up on webinars together but there are others, all of whom are top notch. I find the more I put into my support of the Delphi language the more I discover some truly great people beavering away, all of us with the same shared purpose, often in very different ways, sometimes different countries. We’re all on the same page when it comes to Delphi and RAD Studio though.

We’re also fundamentally a very like-minded bunch – geeky, into things like Star Trek, LOTR and we even discovered today that a few of us are into the movie War Games, partly as a result of me posting pictures of myself, from a few years ago, wearing a T-shirt saying “how about a nice game of chess” while I was standing next to the press podium at Strategic Air Command where they would have announced the beginning of a global thermonuclear war.

Today a gift arrived curtesy of one of those Delphi folk: Zach Briggs. He sent me an official Delphi Mystics coffee mug. It is enormous, as it should be in order to adequately fuel a professional software developer. ?

Quality stuff. Thanks Zach… and thanks to the Trekkies, Holger and the others who keep me sane whilst I knock out program code; you know who you are.

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? ?

Here’s a replay of the video played during the webinar – obviously it doesn’t contain the Q & A because that was live. As soon as the Embarcadero’s official recording of the webinar is available I’ll swap it out.

Note that the link to the repo shown in the video is incorrect – it’s actually ->

https://github.com/checkdigits/fancy_ui

Here’s the slides from the webinar…