balabuev

Tried this already, no luck. Btw, TTreeView with handle re-creation was always strange...

I was not able to reproduce the issue. Tried with Form>PageControl>TabSheet>Frame>PageControl>TabSheet>TreeView. Can you upload simplified demo project?

This is what I've initially talked about.

Manual explicit rearrangement is somewhat different from the formal restoring algorithm (like re-reading from dfm). Anyway, I just highlight possible issues, which I beleive are not intuitive from the first look. May be I complicate things compared to what is practically needed in this particular case.

Will not be sufficient, especially if we want to treat only selected controls, as topic starter initially mentioned. And in the case when parent form (or control) was already resized.

The problem with storing/restoring positions is even more general. If some form have child controls, which use Align and/or Anchors features, then any attempt to reset control positions via iterating the controls and assignings original desing-time positions - is an incorrect way, which may end up with the invalid layout. Especially (but it's not required) when the form is resizeable.

No reasonable way. ExplicitXXX [pseudo]properties are a part of align subsystem data. And they are not actually always stored in dfm.

Well, if you use only utility methods, like ReadStr, ReadSignature, etc - then yes, you right. But this way, you need to rewrite most other high level reading code manually.

This is not technically possible with TReader. However, I want to mention one different aspect: Such a solution will not be a kind of "professional" solution anyway, because controls are not developed having multiple re-loads in mind. Control's code may use different load process related flags, like csReading, csLoading and may override Loaded method. And the developer may (which is often the case) rely on the fact that the loading happens right after creation.

What is more, in some cases compiler can use the same register for several local variables. So, "all" local variables do not even exist at the beginning of procedure.

I've created hacker style fix for the TSpeedButton font issue SpeedButtonFontFix.pas (No need to change or replace any of standard source files. Just add the unit to your project and run) Same fix as design-time package. Fixes the font at design-time: pSpeedButtonFontFix.zip (open in IDE, right click the project file, choose "install" from context menu)

Similarly, should work with records: type TMy = class private FPoint: TPoint; public property X: Integer read FPoint.X write FPoint.X; property Y: Integer read FPoint.Y write FPoint.Y; end; This can even be mixed with static arrays: type TMyData = record Points: array[0..1] of TPoint; end; TMy = class private FData: TMyData; public property X: Integer read FData.Points[1].X write FData.Points[1].X; property Y: Integer read FData.Points[1].Y write FData.Points[1].Y; end;

That's just my guess. However, I remember Turbo Pascal (blue) was a mainstream in schools approx at 1993-1995. And Delphi after that.

I guess the right answer is - No.

To limit msbuild output, I use -clp:ErrorsOnly;WarningsOnly command line parameter. This allow to output warnings and errors only. However, in this case compiler hints are not visible. The question: is there exist any way to include compiler hints to the output, while keeping it clean and free of any other unneeded information?

I've encountered the following strange behavior of the mouse processing. xakvJV4k1M.mp4 Child controls are standard TScrollBox and TStringGrid controls. In this case: - Pressing mouse button over some specific region of a child control's client area magically treated as a mouse event over the scroll-bar. Mouse-down messages are not dispatched to the control in this case. - Clicking on the client area (of the same control) outside of mentioned specific region works normally. - At the same time clicking on scroll-bars also works normally. I've highlighted these inplicit magic regions on the following screenshot. They looks like scroll-bars, shifted some distance to the top: I see such strange behavior for the first time ever. And its interesting, what potentially I should do from WinAPI viewpoint to get such strange offset?

I've checked on Delphi 7 , Delphi 2010, Delphi XE, Delphi XE2, Delphi 10.4.1 - everywhere I've encountered this issue. I think it's more probably an issue of the current Windows build, but I may be wrong. My Windows build: 18363.1316

I thought that the reason may be somewhere inside the docking controls code, but, amazingly, I was able to reproduce the issue with simple standard controls. The project is attached: - Run the project - Press Button1, which will create the second borderless form - Press Button2, which will shift the form down slightly. - Try to press mouse button and drag to the right, as shown in attached video: c40EKHZBnq.mp4 Demo project sources: 102.rar

SaveDC/RestoreDC in such cases are usually used to restore original clipping region, since you change it in the code.

The issue happens due to the fact that you use two not fully compatible ways to deal with the device context (DC): 1) Delphi TCanvas wrapper, which have a lot of lazy initializing stuff. For example, when you change the color of the Brush, the brush object is marked as invalid internally, and its handle will be recreated later - only when needed. 2) WinAPI directly, like SaveDC/RestoreDC, which skips mentioned Delphi internal invalidation. TCanvas.Refresh method is specifically exist to resort cases like this. Try to call it just before ACanvas.Polygon. I can even describe, why red color is a kind of special color, which do not work (as opposed to any other color, like black). And I agree - ColorToRGB is not needed here.

try Exit; // Works. "Finally" code will be executed. finally Exit; // Compile error; but, will work in try/except. end; // ========== for i := 0 to 10 do begin try Break; // Works. "Finally" code will be executed. Continue; // finally Break; // Compile error; but, will work in try/except. Continue; // end; end; // ========== goto L1; // Compile error. goto L2; // try L1: finally L2: end; // ========== try goto L1; // Compile error. goto L2; // finally goto L1; // Compile error. goto L2; // end; L1: L2: // ========== try L2: goto L1; // Compile error. finally L1: goto L2; // Compile error. end; The above is just to summarize different kinds of jumps

Since the main untranslatable word is already "translated" as Chuck Norris the rest is simple: Chuck Norris doesn't read books, instead Chuck Norris write books.

Just more generalized case of the same concept: Can ShowWindow be used to hide the window? Yes. Can EnableWindow be used to disable the window. Yes. This style of naming is a bias towards minimalism. And, imho, being used carefully - it's quite adequate.

In some cases - yes. Imho, it's a kind of subjective things.

But, in this particualr case these two things are related. If the function name expresses a positive action and the boolean parameter also expresses a positive action - then it's a kind of acceptable style. Otherwise, it will be a mess: procedure EnableWindow(AHandle: HWND; AEnable: Boolean); // Good and consistent. procedure EnableWindow(AHandle: HWND; ADisable: Boolean); // Bad. procedure DisableWindow(AHandle: HWND; AEnable: Boolean); // Bad. procedure DisableWindow(AHandle: HWND; ADisable: Boolean); // Bad.