Attila Kovacs

@MichaelT Thank you very much! I see. So I shouldn't be concerned about the quality of version 11, since version 12 is just around the corner? Or 11.4 first? We did not have luck with even version numbers yet. Looks like the only question is whether this LSP is working or not. When you say it works 'time to time,' do you need to restart the IDE or a service, or do you have no impact on it? Or does it just fail in specific places or units? Like the old one?

I know it! All the SQL queries go there. Nobody else needs this.

I've implemented a routine in a wizard that captures the editor ('TMenuBuilder') using Screen.OnActiveFormChange and automatically calculates the menu size from TMenuWin.FNCHeight TMenuWin.FMenuHeight and TMenuItemWin.FCaptionExtent. That task would be suitable for GExperts if there isn't anything related to this matter yet. @dummzeuch ?

I'm confident that the team is doing an excellent job.

Aham, and whats about diffent platforms? is it possible to set up the line break with directives?

1x TButton 5 GDI 100x TButton 5 GDI Someone should be included in this debugging.

And here we go, that's what I was referring to: every piece of trash you find.

of course we can, where is the problem?

I don't think the intention of these blocks is to put every piece of trash you can find into them. I'm laughing my pants off at your suggestion to support multiple encodings and line endings in one text file. It's already pretty strange, and I'm sure it would have never happened if C# didn't implement it first. I'm still skeptical that they didn't do it on April 1st.

It's a bug for sure, either in the component or in your code. Start debugging and don't panic 🙂 First step is, turn on the GDI Objects column in the task manager and start watching it meanwhile you navigate through your app. If you are creating/freeing the forms/frames on the fly as you state, the number should drop back on closing a form, etc... you know it for sure

It's a huge misconception that with these components, you can only create fancy forms. These components work perfectly fine without any styling, offering a lot of added value with great support and being completely affordable. etc...

My apologies. Another question. Would this throw an error in the dreams of a rainbw unicorn? blub := ''' line1 line2, indented 3 spaces line3 ''';

Will this throw an error then? blub := ''' line1 line2, indented 3 spaces line3 ''';

Speaking of code formatter, we need a flag in the built-in formatter to be able to exclude parts of the code formatting.

I can only recommend it to everyone.

I came across this ineresting post https://stackoverflow.com/questions/27368556/trtticontext-multi-thread-issue after getting an error report over an AV in System.Rtti.MakeClosure and I'm wondering, according to the answers from @Stefan Glienke and @David Heffernan if the "data := nil;" in System.Rtti.LazyLoadAttributes,MakeClosure should not be the first after the second check?

I checked it and it's still the same, I should have mention it tough. Ouch. Now that you say, nice one. So basically, my approach to create/try-finally/free the TRtttiContext, which is advocated by some, is also wrong because of the faulty library, and I should instantiate one somewhere at the beginning?

Make te uses list great again!

It's the Dopplebeau effect. Normal. Don't even bother with it.

You asked for thoughts, pros, and cons. Then, you became anxious when I provided you with a point of view and introduced your implementation details (traffic) into the equation, which changed the entire question. But hey, we're used to it 😉 Do you still have any concerns?

Why do you care then? Anyway, "service storing the data" is a kind of middle-tear API too, nobody exposes the DB itself.

How would you manage to allow 20 million users to authenticate simultaneously? You can't. Google can. Some services are meant for the clients, while others are not. Relying on such services always carries some risk, but not necessarily the ones you are most concerned about. Instead of fearing discontinuation, excessively frequent updates, or lack of support,..

I have something similar without regexp and I'm calling it "Open Unit" 😉

Could you help me identify from which Delphi version this works correctly? If it does at all..... Anchors are akTop + akRight original: pressing "+", (scale up with 24dpi) the same thing happens if the anchors are akTop + akLeft + akRigt I'm on Berlin U2. A hint or a patch or workaround would also be appreciated if available. Scale-Test.7z

It seems I can't postpone an upgrade much longer, perhaps I can bridge it until then with this. Very basic, only tested with the form from above, (also inserting/removing components may break it)... unit AnchorPanel; interface uses Winapi.Windows, Winapi.Messages, System.Classes, Vcl.Controls, Vcl.ExtCtrls; type TControl = class(Vcl.Controls.TControl); TControlData = record Anchors: TAnchors; Bounds: TRect; Align: TAlign; IsScaling: boolean; end; TAnchorPanel = class(TPanel) private FOriginalSize: TRect; FControlData: TArray<TControlData>; FCalcWidth: integer; FCalcHeight: integer; FScale: single; procedure SaveControls; procedure ResizeControls; procedure WMSize(var Message: TWMSize); message WM_SIZE; protected procedure ChangeScale(M, D: integer; isDpiChange: boolean); override; procedure Loaded; override; public published end; procedure Register; implementation procedure Register; begin RegisterComponents('Samples', [TAnchorPanel]); end; { TAnchorPanel } procedure TAnchorPanel.ChangeScale(M, D: integer; isDpiChange: boolean); var i: integer; begin if (csDesigning in ComponentState) then begin inherited ChangeScale(M, D, isDpiChange); end else begin SaveControls; inherited ChangeScale(M, D, True); if csLoading in ComponentState then begin FCalcWidth := Width; FCalcHeight := Height; FScale := 1; end else begin FCalcWidth := MulDiv(Width, M, D); FCalcHeight := MulDiv(Height, M, D); FScale := FScale * M / D; end; if not isDpiChange then begin for i := 0 to ControlCount - 1 do begin FControlData[i].IsScaling := True; TControl(Controls[i]).ChangeScale(M, D, isDpiChange); end; end; end; end; procedure TAnchorPanel.Loaded; begin inherited; if not(csDesigning in ComponentState) then begin FOriginalSize := Self.BoundsRect; FCalcWidth := Self.Width; end; end; procedure TAnchorPanel.ResizeControls; var i: integer; begin if FOriginalSize.Width <> 0 then for i := 0 to High(FControlData) do begin if FControlData[i].Align = alNone then if akRight in FControlData[i].Anchors then begin if akLeft in FControlData[i].Anchors then begin Controls[i].Width := Trunc(FControlData[i].Bounds.Width * FScale) + Trunc(Self.Width - (FOriginalSize.Width * FScale)); end else begin if not FControlData[i].IsScaling then Controls[i].Left := Trunc(FControlData[i].Bounds.Left * FScale) + (Self.Width - FCalcWidth) + Trunc(FCalcWidth - (FOriginalSize.Width * FScale)); end; end; FControlData[i].IsScaling := False; end; end; procedure TAnchorPanel.SaveControls; var i: integer; begin if not(csDesigning in ComponentState) then begin if Length(FControlData) <> Self.ControlCount then begin SetLength(FControlData, Self.ControlCount); for i := 0 to Self.ControlCount - 1 do begin FControlData[i].Anchors := Self.Controls[i].Anchors; FControlData[i].Bounds := Self.Controls[i].BoundsRect; FControlData[i].Align := Self.Controls[i].Align; FControlData[i].IsScaling := False; Self.Controls[i].Anchors := [akLeft, akTop]; end; end; end; end; procedure TAnchorPanel.WMSize(var Message: TWMSize); begin if not(csDesigning in ComponentState) then SaveControls; inherited; if not(csDesigning in ComponentState) then ResizeControls end; end. Scale-Test5.7z