Uwe Raabe

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.

I just realized that this is far more complex than I anticipated. The current implementation takes one or more lines and splits them each independently. If a line break is inserted, the remaining text is also handled as if it were independent. Unfortunately that will not work reliable when semantics come into play and some state has to be carried on. Seems I have to re-design the whole approach before it can be used in production.

Well, I am thankful for every test case. The test case should have: the complete line with leading spaces the expected length of the first line after wrapping the wrap margin to use (default = 80) the indent for the wrapped lines (default = 4)

Not something that I am aware of, but there are still areas in MMX which I am not very familiar with. MMX marks the project modified when the MMX settings dialog is closed with OK or Apply is clicked, but nothing of that happened in the video. The weird thing is that I made the test with MMX installed, too - and it did not happen. I do the same test with other projects and not one shows the always compile problem. Can you export the MMX registry key HKEY_CURRENT_USER\SOFTWARE\Raabe Software\MMX\15.0 and send it to me so I may track that down?

As that matches my test scenario pretty close, it may be caused by some differences in our environment. Which plugins do you have installed?

Just clear the entry for the Git exe in Tools - Options - Version Control - Git

Recently I noticed a freezing IDE while loading some source files. The actual cause was the internal Git client prompting for credentials in an invisible console window. Disabling that client fixed the problem.

A simple test doesn't show that behavior here. To eliminate the chance that the application is just too small to make that effect visible, I checked the timestamp of the exe. BTW, the exe is not even recreated when I switch projects inside the project group in between. Can you spot any changed files in the project folder that may be the cause for the effect you are seeing?

One of my customers switched from SVN, Bugzilla, ContinuaCI to Azure DevOps with Git repositories. Only ContinuaCI has been kept - mostly because the switch to Azure Pipelines would have been a too large step for one move. Depending on the range of support for Azure DevOps in the coming releases of ContinuaCI it may as well keep its place as the favored build system for a long time. The switch from SVN to Git was more a mental problem for the developers than a conversion one for the repositories. We made a clear cut in the history and split the monolithic repository in several smaller ones. Common libraries are handled as submodules. Bugzilla tickets were (and still are) moved to Azure DevOps with a self written tool (in Delphi of course). We also use a keep only what is needed approach here and archive the remaining Bugzilla data in a few months or so. The acceptance in the team after these changes is very positive. Things work much smoother as before and previously tedious tasks are either much easier or completely automated now.

Given some proper hardware working in a VM is not noticeably slower. (OK, I can only speak for VMware Workstation here)