Uwe Raabe

You have to activate that option:

You can define the group names per project in MMX Properties - Project options: A single identifier is treated as a group prefix which has to be followed by a dot (like System, VCL, FireDAC). You can also use wildcards like Rz* for all units from Raize Components (KSVC). Unit names not covered in one of the schemes above can be listet in brackets. This is the setting for MMX itself: (ToolsApi,DesignIntf,DCCStrs,DockForm,TabDock);Winapi;System.Win;System;Xml;Vcl;VirtualTrees*;Rz*;Tb*;Png*;MMX The settings are stored in the dproj file.

It needs some code to be added, but you can declare a const array[<enumeration>] of Integer with values 0 in all places where the enumeration is used in some way. const cCheckProjectType: array[TProjectType] of Integer = (0, 0, 0, 0); If you now extend TProjectType the compiler will stop at all places where such a declaration is present and you can inspect the code around for correct TProjectType usage. After that is done you extend the array values to make the compiler continue to the next problematic position.

Very good point 👍

Enclosing the loops with a qryItemReceita.DisableControls/EnableControls should help a bit.

You can still have the first, but nevertheless the second being active. Usually an UEFI BIOS can be made working as an old fashioned one. Unfortunately switching that back to UEFI mode requires some significant work to make Windows boot again.

Two things that are sometimes overlooked: UEFI BIOS TPM 2.0 For the second item there is an article (in German): Windows 11 läuft wohl nicht auf Intel-Macs

AFAIK, there is currently no mechanism to intercept the message display via OTAPI.

Have you checked that opening the relevant FireDAC dataset (whatever is happening in dmParksDB.OpenParks) actually contains data on Linux? I mean, if there is no data in the dataset what can we expect?

I get the feeling that is isn't related to the wait cursor, but the timer implementation that comes with either of the Wait implementation units. While both the VCL and FMX implementations use a TTimer (VCL/FMX), the console implementation simply doesn't support a timer at all.

You can use the console cursor even in a VCL or FMX application. So setting the provider to Console should work in all cases.

Sorting classes is usually not working due to dependencies between them. You might have more luck using MMSDV to compare the files.

DIV and round(/) will give different results depending on input.

QP is merely a bug tracker meant for collecting bugs from users and solve them somewhere in the future (well, in theory). With that in mind, two days are nothing. As the issue is not even opened, probably no one in charge has even took notice. If you want instant support you better open a support case. With an active subscription you are entitled for three issues per year. IIRC the URL is https://idera.secure.force.com/embtsupport/

If the error just could be reproduced here in my environment, I would do. Nevertheless, I will add madExcept in the next release.

The stucture relates to the class and its methods as seen in the tree view to the left. F.i. if only the order of methods in a class changes, be it in the interface or the implementation, the structured difference would rate that as equal. Inside each method the diff is the same as a simple line diff.

Looks pretty decent so far.

Googling that error code gives one usable hint: As I have not the slightest idea which DLL may be causing this I would like to ask if you can try some Sysinternals magic to find that out. It might be related to using Windows 7 and MMSDV being compiled with Delphi 10.4.2.

That is quite similar to what TFDQuery implements with Cached Updates.

Same here. This also helps to keep the VM independent from the host. All my VMs are self contained and can be moved to arbitrary hosts (with capable hardware of course).

And here it is: program Project804; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes; function AddItems(const aArray: array of string; out aList: TStrings): boolean; var S: string; begin { can we really omit this? No! } //aList := nil; for S in aArray do if S.Length > 0 then begin if aList = nil then aList := TStringList.Create; // only create aList if any items gets added aList.Add(S); end; Result := aList <> nil; end; var lst: TStrings; begin try lst := nil; try if AddItems(['Hello', 'World'], lst) then Writeln('True') else Writeln('False'); if lst <> nil then Writeln(lst.Text); finally { uncommenting this will raise an invalid pointer exception later } //lst.Free; end; try { Although being an out parameter, the current lst instance will be used inside AddItems } if AddItems(['Delphi'], lst) then Writeln('True') else Writeln('False'); if lst <> nil then Writeln(lst.Text); finally lst.Free; end; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; Readln; end.

Pascal Analyzer is trying to tell you: "Your method misses to initialize aList before entering the loop, because in case the loop is empty or condition is always false you end up with an uninitialized out parameter aList!" So, yes, it is a valid alert and although you may get away with it in most cases, it may fire back sometimes. It should be possible to create a use case where it fails.

It is probably a button somewhere on the new CustomTitleBar control that is clicked. It can as well be that just the event of that button is wired also to some other button and no titlebar control is directly involved.

Not found units are units that are referenced somewhere in the uses clause, but Analyzer cannot find the unit source for it. Usually that are Delphi units in dcu format. You can extend the search path of Analyzer so that it can find those units. On the other hand you might not even be interested in analyzing these units as you probably have no means to change any of these dependencies then shown. Usually it would only clutter the output.

Seems it is not Classic Code Insight alone. I cannot reproduce with a fresh VCL application with either setting.