Uwe Raabe

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.

The XML Mapper can be installed via GetIt. Edit: Can you explain what doesn't work in XML Mapper?

Exactly! And vice versa.

Could it be related to the scaling value being 125%? I also cannot see that OI problem with 150% scaling. With multiple monitors having different scales it may even depend on the scaling of the primary monitor if different from the one the IDE is located.

The download page offers a Personal Edition which seems to require just a registration.

Try setting both to 0.

I don't really understand. What do you mean with adding variables dynamically? Fields inside classes have to be known at compile time. Otherwise a construct like if MyCompanyData.mlcApplicationGlobalEmails then ... would not compile. The order of the field in the class doesn't matter at all. Basically LoadInstanceFromCurrent iterates all the fields and properties in the class and looks if there is a corresponding field in the dataset its value is assigned to the field of the class.

I have slightly changed the CompanyData unit to get rid of the many class vars in favor of a singleton implementation. Instead of TCompanyData.mlcApplicationGlobalEmails you should write MyCompanyData.mlcApplicationGlobalEmails. With this change you can make use of the DataSetHelper unit mentioned above. You only need to use that unit inside your data module and load the customer data like this: Company.Open; Company.LoadInstanceFromCurrent(MyCompanyData); Company.Close; CompanyData1.zip

Yes, there is. I blogged about it here: Dataset Enumerator Reloaded. The latest sources can be found on GitHub: https://github.com/UweRaabe/DataSetEnumerator. You may need to remove the class var, because the sources are to be used with instance fields. Is there a special reason for using class var?

This isn't only just ridiculous, it is getting really annoying.

Well, without the information about how the data is expected, you will have hard time to find advice here. The swagger description and example of the endpoint you are trying to reach with POST would be sufficient. We don't need access to the whole documentation or even the web service.

I have done that for quite a couple of web services. The critical information is a description of the web service. Regarding your specific 403 problem it is necessary to find out how the data is expected by the service. Do you have some reference for that at hand?

Yes, it reports that warning: