Where NOT to put your Delphi components
February 4, 2021 by Ian Barker
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: “Для просмотра ссылки Войдиили Зарегистрируйся“.
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 like TMS VCL UI Pack 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: Для просмотра ссылки Войдиили Зарегистрируйся
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 –
But if not then maybe this post might save you some of the grief I’ve experienced in the past few months.
February 4, 2021 by Ian Barker
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: “Для просмотра ссылки Войди
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 like TMS VCL UI Pack 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: Для просмотра ссылки Войди
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.
But if not then maybe this post might save you some of the grief I’ve experienced in the past few months.
