How to fix the “teEngine not found” compile error

 Delphi  Comments Off on How to fix the “teEngine not found” compile error
Mar 172021

Today I had a very strange compiler error in Delphi 10.2, that occurred on one computer but did not occur on another computer:

myUnit.pas(28): error F2613: Unit 'TeEngine' not found.

The project was checked out from svn on both computers, so the source code was identical. So the unit “VCLTee.TeEngine” from TeeChart was in a subdirectory of the project sources and the project’s “Search Path” on both computers. But on one computer the compilation worked fine, on the other I got the error above.

The first thing I checked was that the TeeChart sources were not listed in the “Library Path”. I restrict my “Library Path” to the RTL and VCL units that come with Delphi and remove anything 3rd party libraries tend to add. Third party sources go into svn, are project specific and checked out via svn:external.

Further investigation showed that the prefix “VCLTee” was not listed in the Unit Scope Names setting of the project, that’s why the compiler as only looking for “teEngine” and did not find “VCLTee.TeEngine”. But again: How could the same project compile on the other computer? It should have failed on both!

Half an hour later I found the problem: There is also a “Unit Scope Names” setting in “Tools” -> “Options” -> “Environment Options” -> “Delphi Options” -> “Library”. On the computer where the compilation worked, “VCLTee” was listed there, but only under “32 Bit Windows”.

I missed that because the dialog defaults to the “64 Bit Windows” settings.

After I removed this entry, the compilation failed consistently on both computers. (Yes, I call consistent failures progress.)

And after I had added this entry to the project options and synced the sources, compilation finally worked on both computers.

You might ask why it was necessary to have “VCLTee” under “Unit Scope Names” at all, since the uses list should contain “VCLTee.TeEngine” rather than just “TeEngine”. The reason for this is simple: The unit in question is also used in Delphi 2007 projects where unit scoping was possible but no yet used widely. I had the choice whether I wanted the unit compile in Delphi 2007 projects or Delphi 10.2. Alternatively I could have added ifdefs around the uses clause, but since the IDE keeps on messing with these entries I don’t do that.

If you want to comment on this blog post, you can do so in the corresponding topic in the international Delphi Praxis forum.

 Posted by on 2021-03-17 at 16:07

Windows 10 unidentified networks

 Windows, Windows 10  Comments Off on Windows 10 unidentified networks
Mar 112021

Starting with Windows Vista Microsoft has started to take security really serious. That’s a good thing. Unfortunately in typically Microsoft attitude they think they always know best and that the user is an idiot, so it’s best to keep anything dangerous from him.

Fast forward to Windows 10 and the issue at hand:

Windows 10 tries to identify networks and based on that classifies them as private or public. The Windows firewall then changes some settings based on this classification.

Now imagine a computer installed in a special setting that is connected via LAN to some other computers in the same place. Network wise this is an isolated island, there is no connection to any company LAN or the Internet. All computers have fixed IP addresses, so there is no DHCP server involved, and provide network shares to each other.

Unfortunately Windows sees this setup as an unidentified network and classifies it as a public network. This means that many things – in particular network shares – do not work.

And since Microsoft doesn’t trust users to know what they are doing, there is no easy (GUI) way to change this. It used to be possible in Windows 7 but no longer.

So, what can be done? Google turned up lots of different suggestions but the only one that worked for me was this answer on

It gives a PowerShell script which I have adjusted to my needs:

Write-Host "current settings:"
Get-NetConnectionProfile |
  Where{ $_.InterfaceAlias -eq 'NetworkCardName'} |
  ForEach {
    $_|Set-NetConnectionProfile -NetWorkCategory Private

Write-Host "new settings:"
Get-NetConnectionProfile |
  Where{ $_.InterfaceAlias -eq 'NetworkCardName'}

Write-Host "Beliebige Taste um fortzufahren..."

It reads all connection profiles, filters for the one that apply to a network adapter with a given name (which I renamed to make it unique) and changes this profile to be private. It then displays the new settings and waits for the user to press a key.

In order to work, this script must be started with administrator privileges. Of course, that would have been too simple: Microsoft also by default prevents the execution of PowerShell scripts. Again, that might be a valid security measure but in this situation it’s merely a pain in the lower back. So in order to allow scripts, we need to change this setting as suggested in yet another answer on

Start PowerShell as administrator and run the following command:

set-executionpolicy remotesigned

This allows the execution of local scripts, which is what we want. It also allows remote scripts if those are signed, which isn’t particularly what I want but apparently you can’t get one without the other.

Diesmal funktioniert alles [music video]

 Posted by on 2021-03-11 at 14:03