Uwe Raabe

I will never run out of activations, because I use a Named Network License provided by a local ELC server. This allows me to install Delphi on as much targets I want as long as I keep the same user name on all of them.

That's why renewing the subscription is highly suggested. The commercial versions can be run indefinitely. As mentioned before, security patches are very rarely necessary in Delphi. There are plenty of people out there working with Delphi versions years old, if not decades.

Note, that the implementation of TIBase<I> can be in another unit, where neither IFooBroker is known, nor that TIFoo is a type instance for IFooBroker. Nevertheless that unit has to be compiled before the unit containing IFooBroker and TIFoo. The compiler should only allow anything of type I as a parameter for inherited Create. That will rule out to grab any interfaces via Supports or AS constructs. Please file a bug report.

No, MMX is not open source and I don't have control over that fact.

That is a decision made by Embarcadero based on the nature of the patch.

I cannot believe that this is real code. To me it just looks like made up. If for any reason there is a need for a global procedure ResetHoverColor acting on Form1, the straight forward implementation would rather be procedure ResetHoverColor; begin Form1.ResetHoverColor; end;

It is probably in quarantine due to a COVID infection...

Surely I want. I just don't want to implement things that may be valuable to a single person in a special situation. There are way more things to implement that most likely bring benefit to a lot of people in several situations. My time for MMX is limited and I have to take care for what I spend it. Note that I already took this under consideration: Regarding your requests: This would only work on Forms and Datamodules. Frames and all other classes don't have such a global variable. Given that many people suggest to get rid of these global variables, it would be counterproductive to encourage their usage. Besides that this point is somewhat moot given my response to 1. Moving fields from private to public is not something that I would do without asking for consent, which will add some more user interaction to the process. It is easier to select the relevant field(s) in the class and move them to public with the available tools (like selecting public in the visibility dropdown). This all does not even tackle the fact that the resulting code shown is anything but clean.

Believe me, testing is not to blame here.

No.

With developing in 96dpi they probably mean run the IDE with /highdpi:unaware. There is even a separate start menu entry for that. This is best when you need to keep your DFMs compatible with other systems or older Delphi versions.

It is also possible that VMware will have a decent solution then.

VMware has a workaround for ignoring the TPM requirement mentioned in Installing Windows 11 as a guest OS on VMware Workstation Pro/Player and Fusion

I would like to throw in a variation of this scheme. Instead of Postfixes for units I suggest separate folders named like the platform, similar (well, almost) to the IDE doing it with the library search paths. Adding a simple search path .\$(Platform) to the project may be sufficient. The platform specific units are named all the same but reside in their platform folders. Before anyone claims that this prohibits to include these units to the project: You cannot do this with the postfix units either. (Well, you could by IFDEFing the DPR, but this is strongly discouraged. You definitely cannot trick the dproj file for that.)

While working on a tool for cleaning up uses clauses I stumbled upon this beast (slightly changed to protect the innocent): {$if defined(DEBUG) or defined(DEBUG_SPECIAL)} uses {$ifend} {$IFDEF DEBUG} dialogs {$ENDIF} //<some comment about the following ifdef> {$IFDEF DEBUG_SPECIAL} mmsystem, // timeGetTime() messages {$ENDIF} {$if defined(DEBUG) or defined(DEBUG_SPECIAL)} ; {$ifend} If you are only looking for uses clauses inside some Delphi sources and try to avoid a full featured parser, you will have a pretty hard job to detect, parse and interpret that one correctly. So, if you are interested to make any use of such a tool, please do me a favor: Don't write your code that way! It is hard to read for humans anyway.

I tried that, but I don't like the layout.

Although I would rather have them visible until I have read them. After that they only waste space. Not sure if the forum software allows that.

You didn't! The forum moderators did.

Not sure about your environment, but in the browser there is a setting:

In a comment on this SO question someone states: I know that being difficult to judge from the inside, but does anyone have more information about it?

I am just thinking about ways to realize such a remote free beer solution. Perhaps I should make an appointment with our local brewery for a brainstorming.

You can wait a couple of years and collect the subscription price you kept until it pays for the cost of a new license. Combined with a special offer period that can actually pay off. I for myself have decided to stay with subscription and take advantage of these multiple year subscriptions. Paying a bigger amount once will protect me from the yearly decisions to renew, while keeping me always on the latest version. I still can decide which projects to upgrade and which not deciding only on technical reasons (time usually can be neglected then). For me this is definitely the better approach, but it may not be for others.

Which is the main purpose of Uses Cleaner btw. I have to admit that I hesitated a lot before adding the handling of conditionals in Uses Cleaner, simply because I still think it is a bad approach for so many reasons - the IDE being one of them. My goal was to pressure people to get rid of these when they want to use Uses Cleaner efficiently. In a weak moment I implemented it to handle constructs like {$IFDEF USE_CODESITE}CodeSiteLogging{$ENDIF} properly. Probably a big mistake...

The attribute you are looking for is JSONMarshalled: TPersistItem = class(TPersistent) private [JSONMarshalled(False)] FChangeStatus: TChangeStatus; FId: Variant; [JSONMarshalled(False)] FLoading: Boolean; procedure SetId(const Value: Variant); protected Make sure to have REST.Json.Types in your uses clause.

Have a look into the except block of TCustomRESTRequest.Execute and you can see that it catches any EHTTPProtocolException and raises a simple ERESTException for errors >= 500 when this is enabled (it is by default). So you either catch ERESTException or (what I suggest) disable RaiseExceptionOn500 in the TRESTClient and wire OnHTTPProtocolError instead.