Uwe Raabe

I can assure they do know.

@Anders Melander Assuming the property backed by FValue is also called Value, the name of the local variable seems to be a bit questionable. TransformedValue looks appropriate. Then the parameter may indeed be named Value, even if that clashes with the property name. We often have these name clashes that only work because of scope. This could be one of the situations I would tend to actually accept it. At least I rate it much better than fighting with case sensitivity. Could it be we strive a bit off topic here?

Only speculating, but perhaps the delay is due to some major overhaul in respect to this: VCL WelcomePage Making wuppdi Welcome Page a plugin for the new Delphi Welcome Page introduced in Delphi 11 may give us the best of both worlds.

Indeed there is. That has probably been the trigger to revamp the old style guide to support the newer language features and establish it inside the developer team at Embarcadero. I hope we can expect more consistency here in the future. That doesn't invalidate the argument, though. The standard style is widely spread and most developers are quite proficient to read it. A lot of style guides in the wild are more or less small variations (if at all) of this standard. You won't ever surprise any developer presented with sources following this style. That somehow makes it unique and means it has an advantage.

Of course, everyone has its own take on these things. Most preferences just came out of habits. You like what you do and everything else looks strange. That doesn't make one superior to the other if taken out of your own perception. I'm still proposing the original style guide now available in a newer form: Delphi’s Object Pascal Style Guide. Not because it is superior or more readable. A big advantage is that I don't have to switch mentally when looking at the Delphi sources (although they don't even adhere to it everywhere) and my own sources. That said, a style guide is something a team has to agree on and follow it. While this can vary from team to team, it is not a strict law that has to be enforced. That's why it is called Guide instead of Rails. At the end, style guides evolve as Marco perfectly states in his article New Delphi’s Object Pascal Style Guide:

Having a concrete test is always useful.

I cannot see the part where FDQuery actually makes use of the pooled connection montetest.

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.