Uwe Raabe

I happen to have downloaded a copy right after publishing. Here it is... Object_Pascal_Style_Guide_-_Developers_Guide.pdf

I'm not even sure that Embarcadero can do much about it. AFAIK the server infrastructure is managed by the Idera IT department. Not rating that as an excuse, though. On the other hand, there still is the Offline Help.

Welcome to the club! For me it often helps to refresh the captcha a few times before answering it.

Indeed! I have been struggling with this myself several times. Often providing a fix is simpler than constructing a decent test case.

That is quite some valuable information. 👍

Can you provide a concrete example? The people responsible for that are way more open for discussion when they have a actual code that fails.

At the end it doesn't matter which norm we use to write that grammar in, as long as we provide ways to convert that to whatever a target tool expects. So if we decide to hop on e.g. ABNF, we should create a companion converter to at least BNF as a common denominator.

That is not quite right. It is FCurrentPPI that copied to FPixelsPerInch, but you are showing CurrentPPI and PixelsPerInch instead. While the latter retrieves FPixelsPerInch inside TWinControl.GetPixelsPerInch, the former not always does that for FCurrentPPI in TControl.GetCurrentPPI. There is a chance that GetDPIForWinow retrieves another value as is stored in FCurrentPPI. Of course that can still be some error - and it probably is.

There also is TFDDataSet.CopyDataSet, which takes any TDataSet as source. So if your target dataset is derived from TFDDataSet (like TFDQuery) this could be an option.

Yeah, it doesn't look like clean BNF at all. Any BNF parser I tried has had its problems with it.

I guess the problem is the use of semicolons in the grammar to separate the rules, which seems not to be standard BNF.

They probably all vanished in an empty except-end block.

Could it be that the DB field value is Null when it crashes? Can you please try to adjust the LoadFromField code to this: procedure TDataSetHelper.TDataSetRecord<T>.TPropMapping.LoadFromField(var Target: T); var val: TValue; begin if FField.IsNull then val := TValue.Empty else val := TValue.FromVariant(FField.Value); FRTTIProp.SetValue(GetPointer(Target), val); end;

I thinks it is: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Properties_(Delphi)#Class_Properties

Only if there were a feature request that has been implemented.

They are static by design. The why I cannot answer. Unfortunately there is nothing we can do about it. Instead class properties you may have to switch to class functions. These can be virtual.

Class properties are static and thus cannot have virtual getters or setters. That is because static members have no information about the actual class they are called on. They only know the class they are declared in.

Perhaps it is just my take of it, but being a contributor bears some responsibility - for the whole repository and not only for the part you contribute. I wouldn't call that lowering the barrier. On the other hand, forking the repo, doing your thing and creating a pull request seems much less hassle to me. Anyway, everyone can just do so whatever you decide.

Have you considered keeping the number of direct committers small and let the majority of interested participants provide their contributions via pull requests?

No, at least not necessarily - unless you only have one core. The OS thread scheduler will take care of running it on whatever core is available.

If you make use of some newer features of the RTL you can also write: uses System.SysUtils, System.StrUtils; function ListContains(const PList: string; PNumber: integer): boolean; begin Result := MatchStr(PNumber.ToString, PList.Split([';', ','])); end; An advantage is the simple support for additional separators.

Perhaps we should forward this to @Daniel

This has already been brought up right at the start of this forum. If it were just a simple setting to be changed, I am pretty sure it would have been accomplished long ago.

The Delphi streaming system knows that it handles TComponent descendants only. That way it can create each instance calling <SomeComponentClass>Create(<Owner>). In contrast TJSONUnMarshal.ObjectInstance works on any class having a parameterless constructor. It cannot rely on TObject.Create for that as it is not virtual. So the mechanism behind both approaches is totally different. I just wanted to emphasize that.

Yes, but it only works for components because TComponent has a virtual constructor.