Jump to content

balabuev

Members
 View Profile  See their activity

  • Content Count

    241

  • Joined

  • Last visited

  • Days Won

    2

Posts posted by balabuev

  3. Posted

    1 minute ago, Attila Kovacs said:

    He also mentions that he is successfully hides/resizes/rearranges those components

    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.

     

     

  5. Posted · Edited by balabuev

    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.

  8. Posted

    21 hours ago, aehimself said:

    I'm wondering if it's possible to re-read and re-apply the .DFM settings to a number of selected components

    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.

     

     

     

    • Like 1

  11. Posted · Edited by balabuev

    13 hours ago, vfbb said:

    such as accessing an item in an array just by declaring a property, without any method

     

    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;

     

     

    • Like 2

  15. Posted · Edited by balabuev

    I've checked on Delphi 7 :classic_biggrin:, 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

  16. Posted

    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:

     

     

    Demo project sources:

    102.rar

     

     

  17. Posted

    I've encountered the following strange behavior of the mouse processing.

     

     

    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:

     

    image.thumb.png.5c50bfe9f9ed354cb76f4aaf4b01ef72.png

     

    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?

     

     

  18. Posted · Edited by balabuev

    On 1/29/2021 at 6:07 PM, c0d3r said:

    Solved the issue, but I don't understand the reason why, I had like:

     

    SaveIndex := SaveDC(Canvas.Handle);

    try

       IntersectClipRect(Canvas.Handle, .....);

       PaintRows(Canvas, ...);

    finally

        RestoreDC(Canvas.Handle, SaveIndex);

    end;

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

     

     

    • Like 1

  19. Posted · Edited by balabuev

    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.

    • Like 1

  20. Posted 

    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 :classic_biggrin:

     

    • Like 4

  22. Posted

    14 minutes ago, Fr0sT.Brutal said:

    There is multiple SW_* variants so the example is irrelevant...

    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.
    23 minutes ago, Fr0sT.Brutal said:

    Nice sample of bad naming, yes.

    This style of naming is a bias towards minimalism. And, imho, being used carefully - it's quite adequate.

     

     

  24. Posted

    5 minutes ago, Mike Torrettinni said:

    although the point wasn't about the actual naming, but that boolean parameter does 2 opposite actions

    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.

     

×