Separate cache directories per platform in the Uses Clause Manager in GExperts

 Delphi, GExperts  Comments Off on Separate cache directories per platform in the Uses Clause Manager in GExperts
Aug 082021

The Uses Clause Manager in GExperts has an “Identifier” tab that can be used instead of the Find Unit refactoring of the Delphi IDE (which for me doesn’t work most of the time and if it does is very slow). And of course the Uses Clause Manager also works for older Delphi versions which simply didn’t have this refactoring.

For this to work it parses all source files in the various search paths of the project. And because this takes a while it caches the results and only updates this cache if a new unit is found or a unit has been changed.

Until recently this parser was assuming that the current project is a Win32 application and set the conditional defines accordingly. Later I chanted the conditional defines depending on the currently selected platform but this caused a problem: Units parsed for different platforms ended up in the same cache so it was possible that the lookup was showing wrong results or at least the “Open Unit” button placed the cursor on the wrong line.

Today I changed this to use separate cache directories for each platform, so this problem should no longer occur.

There is not yet a GExperts release containing this change. If you want to use it, you will have to compile your own DLL which is much easier than you might think.

btw: Did yo know that Stefan Glienke has published a similar tool called Delphi Uses Helper? Mine of course is better and much faster. 😉
(Actually it depends on your computer and the project size. On my computer for large projects both tools are about on par, but mine is more flexible. Stefan thinks otherwise. But check it out yourself.)

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-08-08 at 10:00

Separate lists for VCL and FMX in GExperts Rename Components expert

 Delphi, GExperts  Comments Off on Separate lists for VCL and FMX in GExperts Rename Components expert
Aug 072021

The Rename Components expert in GExperts now has separate lists for the names and additional properties for VCL and FMX components. Previously it was a hassle to have additional properties shown in the rename dialog if these have different names in VCL vs. FMX e.g. the Caption vs. Text property of TLabel. Now you simply configure them differently.

This is the configuration for a VCL label:

And this for an FMX label:

Now the expert checks which designer the current project is using and selects the proper list for it.

So, for a VCL label the rename dialog looks like this:

While for a FMX label, it looks like this:

There is not yet a GExperts release containing this change. If you want to use it, you will have to compile your own DLL which is much easier than you might think.

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-08-07 at 15:24

When initramfs gives you cryptic error messages

 Linux  Comments Off on When initramfs gives you cryptic error messages
Jun 222021

Note to self:

If during a Linux update you get the following error:

update-initramfs: Generating /boot/initrd.img-whatever
W: initramfs-tools configuration sets RESUME=UUID=some-uuid-goes-here
W: but not matching swap device is available.
I: The initramfs will attempt to resume from /some/device
I: (some-other-uuid-goes-here)
I: Set the RESUME variable to override this

Check the content of the file /etc/initramfs-tools/conf.d/resume which sets the above mentioned RESUME variable. It probably contains an old UUID. Change it to the correct one and rebuild your ramfs with

update-initramfs -u

That should do the trick.

The current swap partition is usually given in /etc/fstab.

I found this information on this blog.

 Posted by on 2021-06-22 at 18:34

Limited GExperts support for Delphi 6

 Delphi, GExperts  Comments Off on Limited GExperts support for Delphi 6
Jun 202021

A few weeks back something happened with my Delphi 6 installation which now results in an access violation every time I start the IDE. I tried for several hours to find and fix the problem to no avail. It’s not GExperts related, disabling the DLL was the first thing I tried. Now I’m giving up. This will mean that while GExperts will still continue to support Delphi 6 and I will compile a dll with every release (as long as the command line compilation still works), I will not be able to debug and fix any issues.

If you are still using Delphi 6 you are invited to take over this task. I will of course mention you in the credits if you do.
(There is no money in GExperts, just whatever fame there still is left. I’m getting less in donations than I pay for this website. And I usually donate even that money to other tools that I use regularly.)

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-06-20 at 15:51

GExperts and older / unpatched Delphi IDEs

 Delphi, GExperts  Comments Off on GExperts and older / unpatched Delphi IDEs
May 162021

GExperts is always compiled with the latest update of any of the supported Delphi versions. That unfortunately means that it may not work if the IDE hasn’t been updated to the latest version. E.g. The latest GExperts release will not work with Delphi 10.2, but only with Delphi 10.2.3, the latest update to Delphi 10.2. This is due to changes in the runtime packages that are not always backward compatible.

Until a few years ago, this was no problem because when you bought Delphi you were automatically entitled to receive all updates for this version. E.g. if you bought Delphi 2007 you could download all updates for it and GExperts would simply work for you.

This changed when Embarcadero tried to force all their customers to buy a maintenance subscription. Now, if you don’t have such a subscription, you will no longer receive updates and bug fixes. You automatically get a subscription for 1 year when you buy a new Delphi license so this sounds like a minor issue. But a subscription not only gets you updates but also upgrades to the yearly major releases, e.g. from 10.2 to 10.3.
So, if you do not extend an existing subscription shortly after a new major release you will not get updates and bug fixes for this release. You have only two options then: Stick with the previous major release + all updates and bug fixes, or keep using the latest major release and hope that you don’t need the updates for it. Of course that’s on purpose to keep customers extending their subscriptions.

This also affects GExperts: If you are stuck using a non-updated major release GExperts might not work for you.

I have been asked whether I could make releases for these cases. Unfortunately this would require me to keep all minor Delphi releases around, e.g. 10.2, 10.2.1, 10.2.2 and 10.2.3. These cannot be installed on the same computer so that would mean 4 virtual machines for Delphi 10.2.x alone + several for other major versions. Yes, I could do that. But since GExperts is currently a one man (me) show, it would take quite a lot of my time for very little gain. (But everybody is invited to contribute!)

So, what can be done? If you are one of those people affected by this, simply build your own DLL. It’s not difficult at all. This will create a DLL that is compatible to the Delphi version you are using, so your problem is solved.

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-05-16 at 16:59

Adding a Windows 10 computer to a Samba (NT4) domain

 Linux, Windows, Windows 10  Comments Off on Adding a Windows 10 computer to a Samba (NT4) domain
May 042021

Microsoft is trying to force everybody to update from the old NT4 domain system to the “new” (as in “was new >10 years ago”) Active Directory system. While that’s probably a good idea for most people there are some like me stuck with a working Samba installation that for some reason needs to continue to use NT4 domains.

Getting a Windows computer to join such a domain has become more difficult with Windows 10. Here is what needs to be done (I write this mostly so I can look it up myself):

  1. Make sure your samba server is configured to enforce the NT4 (SMB1) login. samba.conf must contain the following entry:
    // other entries here
    server max protocol = NT1
  2. Install the SMB1 protocol on the Windows computer. This is done using the “Turn Windows Features on or off” dialog (just type this into the start menu). You need to set the check marks for two entries under “SMB 1.0/CIFS File share Support”:
    • SMB 1.0/CIFS Client
    • SMB 1.0/CIFS Server

    I’m not 100% sure whether the latter is required. I haven’t tried it without.

  3. Add the following entries to the registry:
    Windows Registry Editor Version 5.00

    You can either add them manually or copy the above to the .reg file and import that into the registry.

  4. Reboot the computer to activate these changes.

Now it should be possible to join the Windows 10 computer to the Samba Domain.

Source: Required Settings for Samba NT4 Domains on the Samba Wiki.

 Posted by on 2021-05-04 at 15:32

GExperts bug: CTRL+V on FMX form designer inserts into secondary editor window

 Delphi, GExperts  Comments Off on GExperts bug: CTRL+V on FMX form designer inserts into secondary editor window
Apr 112021

I got a bug report for GExperts and Delphi 10.4 that’s really curious:

When a secondary editor window is open in the IDE and the FMX form designer is active, trying to insert a component from the clipboard into the form inserts the textual description of that component into the editor windows instead.

I could immediately reproduce this but finding the culprit took quite a bit longer.

Observation 1: It does not happen for the VCL form designer.

Observation 2: It only happens, if you use CTRL+V to insert the component. The form designer’s context menu entry works fine.

Observation 3: Even disabling all experts in GExperts did not solve this problems… Until you restart the IDE, then it’s gone, even if you then enabled the experts again… Until you restart the IDE again which brings it back.

After a lot of trial and error I found that the cause are two of the GExperts editor experts:

  • Goto Previous Modification
  • Goto Next Modification

Disabling these experts and restarting the IDE solves the problem.

These are rather simple experts that only add entries to the editor window’s context menu for a functionality that already is part of the IDE. I added them to make that functionality more visible, and because I could. Since Delphi 10.3 I had to use a workaround to still be able to add entries to that menu because apparently it is being recreated in the OnPopup event. I think this code somehow activates the menu entries or their associated actions even if the editor window doesn’t have the focus.

So for now until I find a real workaround: If you have this problem, disable these two experts.

(The workaround might be to remove these experts altogether. They aren’t that useful anyway.)

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-04-11 at 18:06

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 SuperUser.com.

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 SuperUser.com:

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