Uwe Raabe

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.

This can also happen when the missing DataSource is not located at the same form/frame as the DB components and the IDE fails to open the datamodule (or wherever this datasource resides) for whatever reasons. I had similar experiences with actions located in a datamodule. If by any chance that datamodule shares its name with one of the IDE internal ones (including those in 3rd party modules) that can be the cause of breaking the linkage.

The settings are in the same dialog as the list of recent files and projects. The default is 10 projects and 15 files.