Uwe Raabe

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.

The second call seems to have some query parameters inside the URL while the first one does not. This issue has a workaround in the comments: https://quality.embarcadero.com/browse/RSP-35365

Perhaps similar to this one: LSP Ctrl+Click navigation fails when only DCP's referenced

Historically the IDE uses several parsers for different functionality. The goal is to move all these to the new LSP approach, but that needs time.

Although that might be the case, I recently turned to form a habit that avoids anything causing exceptions inside constructors. That may also lead to avoid giving parameters to constructors - at least when they are not being handled seamlessly during the lifetime of the instance. That allows to concentrate on the real work to be done instead of figuring out some tricky handling of edge cases. LA := TRaiseOnMinus.Create; try LA.Initialize(AInputA); //<== PossibleRaise LB := TRaiseOnMinus.Create; try LB.Initialize(AInputB); //<== Possible Raise { do the normal stuff with LA and LB } finally LB.Free; end; finally LA.Free; end;

Probably something in your code we cannot see that the parser stumbles upon.

Unfortunately that won't work. High-DPI is not something the plugin initiates, it is the IDE doing that. The plugin just has to support it. The same with VCL styles. The IDE activates it and the plugin just has to cope with that somehow. Given that styling and dpi glitches are usually highly visible, they are the first that get reported. That may render the plugin unusable. That said, I am also a bit disappointed by the delay. On the other hand, I can imagine the challenge behind it.

Yeah, that's kind of a chicken and egg problem. The simplest approach would be to execute MMX_Setup again.

Yes. it should. It is the search field for IDE Insight and should find almost everything that the IDE is aware of.

You can open a second edit window and (since D11) put the form designer in that one. That will mimic the former floating designer pretty well.

Sometimes it helps to rename the datamodule to avoid a name clash with the internal one. Naming a datamodule dmImages may be OK for a standalone application, but for an IDE plugin that seems not to be wise. I made this experience myself.