Uwe Raabe

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.

Because POST and PUT need some appropriate server action to achieve the desired result. The web server implementation resolves a GET to an existing file by providing the file content just as it were a static HTML page. On the other side there is no standard implementation to update, replace or create the file via POST or PUT. This feature has to be implemented to be used. Imagine every user accessing your web server could change the static web pages by simply calling PUT or POST. The standard solution for your problem would be using FTP. An FTP server has separate access control and allows writing on a per user/folder/file basis.

That's basically the same. Just imagine, the file is not existent, but the server produces the content on the fly. The result from a GET would be the same. How do you think could you change such a response?

What is written in the documentation for the server how to upload that file? If the request succeeds, what is in the response content?

Fixed in V15.0.49

Check your library paths for 64-bit.

Most likely printing unit sources has been in no ones mind when dark theme was introduced. I suggest filing a QP report. Otherwise this will for sure never be taken care of.

It only has an effect when VCL styles are used. For plain VCL applications it has no influence.

Unfortunately it was never designed to support C++ Builder. So, while this specific functionality may work, I doubt it would justify to install the whole product with near to none additional benefit.

In Delphi 11 there is an option to speed up VCL styled applications which is probably not commonly known, because it wasn't communicated much: Vcl.Themes.TStyleManager.UseParentPaintBuffers While the linked doc is pretty much useless, the common description gives some more insight: Styles Performance Improvements

Storing an interface in a pointer stinks right from the beginning.

That is the error described in RSP-35365. Fortunately Embaracdero provided a workaround in the comments to the issue. That makes it pretty sure being included in the next update.

Well, as I said, I couldn't test it. Fortunately the class helper approach lets us implement a working solution at one place: procedure TListItemHelper.SetSnapTally(Value: ISnapTally); var I: ISnapTally; P: Pointer absolute I; begin P := Data; I := Value; if Assigned(I) then I._AddRef; // because when I goes out of scope the refcount is decremented Data := P; end;

Assigning an interface to a pointer skips reference counting. Thus the instance behind snap_Tally is destroyed when leaving the scope (that's the end in your code snippet). Next, when you retrieve li.Data, you cast it as TSnapTally despite the fact that you assigned an ISnapTally before (disregarding that the instance is already freed). That won't work either, because assigning nil to a Pointer doesn't trigger the reference counting even if there is an interface instance behind it. I cannot test it in the moment, but you might succeed with the following approach: if not Assigned( ARDomainsLV_ItemWithCaption( deets[n], li ) ) then begin var snap_tally : ISnapTally; snap_tally := TSnapTally.Create( aSnap ); li := AnalysisResultsDomains_lview.Items.Add; li.Caption := deets[n]; li.SubItems.Add( '' ); // #detail recs li.SubItems.Add( '' ); // LM (1,2,3) li.SubItems.Add( '' ); // Org 1-10 li.SubItems.Add( '' ); // Org 11-20 ISnapTally(li.Data) := snap_tally; // this should add the ref count properly end; TallyToListItem( li, dom_deets, aSnap ); . . . procedure TallyToListItem( li : TListItem; aDomDeets : TDomainDetails; aSnap : TLSHMSnapshot ); var st : ISnapTally; begin st := ISnapTally( li.Data ); // proper ref count st.IncNumDetailRecs; . . . ISnapTally( li.Data ) := nil; // proper ref count For simplicity I would introduce a class helper for TListItem that captures all these castings: type TListItemHelper = class helper for TListItem function GetSnapTally: ISnapTally; procedure SetSnapTally(Value: ISnapTally); property SnapTally: ISnapTally read GetSnapTally write SetSnapTally; end; function TListItemHelper.GetSnapTally: ISnapTally; begin Result := ISnapTally(Data); end; procedure TListItemHelper.SetSnapTally(Value: ISnapTally); begin ISnapTally(Data) := Value; end;

I wonder what happens when you click on Code Editor...

I am a bit with @David Heffernan here: As long as I am the only one using the classes or even the team is, I tend to avoid checks for parameters or correct usage - despite documenting it in the comments (like XMLDOC) of course. For myself and the team I expect to take care to do it right, otherwise running the test suite will (should) surface that early enough. In contrary, writing library code exposed to arbitrary users requires a bit more defensive programming, at least for the interface part the user is accessing directly.