Uwe Raabe

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.

Would you expect this code issue such a warning? {$APPTYPE CONSOLE} procedure EchoLineUntilEmpty; var S: string; begin repeat Readln(S); Writeln(S); until S = ''; end;

In theory the chance of a 32-bit pointer being 0 is 1:2^32 while the chance for a 64-bit pointer being 0 is 1:2^64. That is quite a big difference. I am aware that this estimate is probably pretty wrong because the memory contents are anything but evenly distributed. If you have some spare time you can analyze the 32-bit code and find out if some other method called clears the part of the stack later used for sl with zero most of the time. Note, that the benefit of this research is just to ease your mind.

Only a link, no more information. Looks not very seriously to me.

That has never been necessary using MMX. Renaming the property automatically renames the field, getter, setter and optionally all references to the property in the current unit. Also related to MMX: Using read/write properties allows to make use of the reverse assignment tool.

This is exactly what I'm trying to do: You missed to quote my suggestion to the end: procedure TForm2.Button1Click(Sender: TObject); begin Edit1.Text := inttostr(TChild.GetChildId) { <= Calling the Child's class function} end;

The docs give some hints: That implies, that they have no idea on which class they are called on and always use the class they are declared in to access any non-static class method. Unfortunately, what you are trying to achieve is not possible this way. Use a non-static class function instead of a class property.

A datamodule has its advantage when component properties are loaded from the DFM - that includes wiring of components and event handlers. (I am aware that some see that as a disadvantage) Another point is that, if you don't actively prohibit that, ist is registered in Screen.DataModules and can be found without that dreaded global instance variable.

Well, I also have no more info as the docs provide. In my personal experience I didn't notice any quirks when skipping the SDK installation.

The docs are pretty clear: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Installation_Notes#Windows_10_SDK

I will have a look ASAP.