Uwe Raabe

That is exactly what I tried to address with Package Magician. Unfortunately some poorly programmed packages just refuse to unload correctly, which sabotages the task of Package Magician.

Currently not at design time (but a good feature request). You can write a small program that does this: for I := 0 to PngImageList1.Count - 1 do PngImageList1.PngImages[I].PngImage.SaveToFile('Image' + I.ToString);

And that lead to the first picture? And this results in the second one? Sorry, but I just try to get the steps leading to the problem. Can you either list exactly what you are doing - or better make a short video?

Are these different desktop files or the same?

That is my impression, too. AFAIK, the CE is technically equivalent to the Professional with the same license limitations (apart from the CE ones of course). While it is even possible to target remote servers with FireDAC in the Professional Edition it is just not allowed license wise.

Indeed, that is currently a known limitation.

BTW, a probably more recent version of the the code is available at https://github.com/UweRaabe/DataSetEnumerator

Are your with that? The docs about csFreeNotification say: That said, csFreeNotification is set when another component wants to be notified when the current component is destroyed. There is no specific action ongoing while csFreeNotification is set. In addition, csFreeNotification is only set but never unset.

Perhaps a QP entry might be helpful?

... and makes that TEditWindow instance the owner of a to-be-scaled TCustomForm. What bothers me more ist the csFreeNotification condition at the end. I mean, how is that related to scaling?

Just a note: A check for old = new length is only sufficient if the array is of one dimension. Even if the length in the current dimension stays the same there can still be changes in the inner dimensions.

That is probably because of these new lines: if MatchText(TPath.GetExtension(SourceName), ['.dpr', '.dpk']) then begin UsesHelper.Compressed := False; UsesHelper.GroupNames := ''; end;

BTW, the sources are now on GitHub: https://github.com/UweRaabe/UsesCleaner (documentation still has to be done)

It was not the IFDEF, but the parsing of a form unit in the uses clause failed. Can you give this version a try, please? UsesCleaner.zip

OK, the IFDEF looks suspicious. Will have a look later.

Can you provide the original dpr file?

Well, uses clauses in dpr files are a bit special. They are always formatted as one line per unit. The unit name can be followed by an in construct followed by a file name. After that can be a form name or a frame or datamodule declaration. Reordering the dpr uses clause can have severe impacts on the functionality of the program. Given that the support for dpr files would probably have to be restricted to resolving aliases and expanding unit scope names. Just curious, have you tried formatting a dpr with settings Compressed = 0 and GroupNames empty?

I found a possible cause for the crash, but cannot figure out the condition to make it happen. Nevertheless I changed some code to be prepared for that case and have uploaded a new version. Can you please try if this solves the problem?

This can happen when MMX was installed for all users. In that case the uninstall is not able to remove these entries from the user registry branches. This is one of the reasons why the setup recommends an installation Just for me.

Unfortunately I am not able to reproduce that here - neither with 10.3.3 nor with 10.4.1. Can you reproduce it right from the start or has something to happen before?

You can switch to the Classic Code Insight and then back to LSP.

Well, Fork supports Git-Flow since V1.17 (2018) ... I'm not familiar with the issue tracker integration of GitKraken, so I cannot say how it compares to that in Fork.

Indeed! It was just today that I had to watch someone working with TortoiseGit, which definitely affirmed my choice of Fork.

https://quality.embarcadero.com/browse/RSP-29357

Thanks! That is some real valuable information. What pops out in the change log between these two versions is the update to a newer VirtualTrees version (7.0 -> 7.4). When I get some time I will try to reproduce that here and track down the cause.