Uwe Raabe

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:

Agree. I prefer Pascal Analyzer to get notified about problems like the one this thread is all about. In contrast to the compiler, eliminating all warnings from Pascal Analyzer is not the goal. If I don't want to get notified the next time I can suppress it with a simple comment.

As I said, this may not always be possible:

I agree, Enable(True) is just bad. It is either Enabled := True and Enabled := False or Enable and Disable; It is quite similar to TDataSet having Active, Open and Close. Side note: we can see a problem here where Open can bei either a state or an operator. Thus I prefer the Is prefix for states: IsOpen, IsEnabled for clarity. (Is only serves as a placeholder here for syntactical equivalents appropriate for the used wording and intention).

One could argue that an out parameter counts as initialized while a var does not. Due to the history of var/out that doesn't work in a consistent manner. As @Dalija Prasnikar said, out has its merits, too.

There are probably plenty of methods, built-in or from 3d party libraries, that offer only var parameters where out would be the better choice, but we are not able to change the signature.

If a variable is given to a method as var or out parameter that should be sufficient to rate that variable as initialized inside that method. If that would always issue a warning, you will have to make a redundant initialization just to make the warning vanish. I strongly reject this request.