Uwe Raabe

and for class var.

I know, that probably won't solve your problem, but I usually get rid of these kind of enumerations in favor of proper ones supported by RTTI. The numerical values are handles by record helpers: type TReportTypeCode = (reportTypeCodeSTR, reportTypeCodeLCTR, reportTypeCodeCDR, reportTypeCodeLVCTR, reportTypeCodeEFTR); TReportTypeCodeHelper = record helper for TReportTypeCode private const cMapping: array[TReportTypeCode] of Integer = (102, 106, 113, 14, 145); function GetAsInteger: Integer; procedure SetAsInteger(const Value: Integer); public property AsInteger: Integer read GetAsInteger write SetAsInteger; end; function TReportTypeCodeHelper.GetAsInteger: Integer; begin Result := cMapping[Self]; end; procedure TReportTypeCodeHelper.SetAsInteger(const Value: Integer); begin for var idx := Low(Self) to High(Self) do begin if cMapping[idx] = Value then begin Self := idx; Exit; end; end; raise EInvalidOperation.Create('invalid Integer value for TReportTypeCode'); end; Now there is no more casting to and from Integers.

IIRC, they dropped the use of MS Document Viewer a while ago. While there are help items for a handful of Windows functions, there also is a hint to the MSDN online library, which IMHO is always the better up-to-date source.

Strange - this is what I see:

Perhaps the server outage made it one.

Given the use of Data in the following lines, I suspect that the begin end should wrap a much larger region.

👍

Reading the code despite of its irritating formatting reveals the problem: WorkOrdersSelectedRow := WorkOrdersGrid.Selection.Top; if FWorkOrderManager.GetWorkOrderDataByIndex(WorkOrdersSelectedRow - 1, Data) then // evaluates file index FileIndex := ARow - 1; if (FileIndex < 0) or (FileIndex >= TWorkOrderData.FILE_DATA_SIZE) then Exit; FileIndex will not be initialized when the if clause fails. BTW, it also irritates that the compiler is charged guilty first.

Essential Delphi Add-ons

I would love to see a bug-fixes-only release, but I am realistic enough to put my hopes pretty low. I also know that a lot of complaints about missing new features will be triggered by such a release.

Mean as I am, I tried to pester the wizard with a pretty big chunk: https://github.com/microsoftgraph/msgraph-metadata/blob/master/openapi/v1.0/openapi.yaml Unfortunately it fails with a

A look into the GitHub repo reveals:

Current version is available on GitHub: https://github.com/UweRaabe/CompressPath

That's what I was actually poining to.

and a bit more sophisticated: reFind.exe, the Search and Replace Utility Using Perl RegEx Expressions

Recovering Connection (FireDAC)

I have a task scheduled exactly for that.

The plethora of working Delphi programs are proof that there already exist concepts to eliminate dependencies between units. They may differ from those available in other programming languages, though. IMHO, circular dependencies should be eliminated even if they appear in implementation sections and thus making the code compile. I wouldn't support any request to extend that in any way leading to more circular dependencies.

Only if you don't make use of Change Views. AFAIK, it also lacks Column-level Encryption.

I guess everyone has got that now.

AFAIK, the Delphi IDE Menu Designer did never support images.

So they seem not to be able to manage it even when they hire the developer. Obviously that is more wishful thinking than perception of reality. I simply cannot see anything like that going to happen in the foreseeable future. BTW, I still even refuse to provide MMX via GetIt for several reasons.

At least back then they had no interest. Current state: it is actively maintained it is available for a couple of recent Delphi versions it is free for all Delphi SKUs Would you bet on all that not going to change?

I always try to get my projects on the most recent versions as soon as they enter a state where I can benefit from the features while being able to tame the defects. The less active a project is, the larger gets the gap between the used version and the recent one. Nevertheless, also these projects are moved to newer versions, albeit on a slower rate. Some customer projects have to stay on older versions, either due to decisions out of my realm or lack of demand for maintenance and enhancements. Whenever either becomes necessary I also try to get this on a newer level. Usually the costs for that cancel out with the higher effort of maintaining it with the older version. Whenever I am forced to work with any of these older versions (mostly D2007 or XE2) I immediately realize why I always prefer to avoid doing so.

There is also time playing a role here. While Delphi 1 had most likely a pretty low number of bugs, it is not usable in these days at it produces code for 16-bit Windows. Also the often praised Delphi 7 runs pretty unstable in a modern environment. Let alone all those "feel-like-bugs" of none existent behavior.