Uwe Raabe

I couldn't reproduce, but I am on 12.3 here.

Can you give detailed steps to reproduce? Perhaps I tested something plain simple while the real problem is more complex.

6 minutes ago, DelphiUdIT said:

Out of haste or inexperience, everything is put into a few units and then ... "you can't unring the bell".

Well, in this case you can. I did a lot of refactoring such code myself during the last decades. The constraint you suggested to remove is a good indicator of progress in such an endeavor.

There are several bugs fixed in 12.2 and 12.3 affecting frames.

https://quality.embarcadero.com/browse/RSP-37402

https://quality.embarcadero.com/browse/RSP-39847

https://quality.embarcadero.com/browse/RSP-40110

https://quality.embarcadero.com/browse/RSP-43560

https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-1020

Perhaps these will fix your problem, too.

I will test your project later when I've found some time to configure my system for monitors with different dpi.

2 hours ago, jesu said:

Yes, Windows 11 Notepad screws files. This never happened in Windows 10 after many years using it. You open a file double-clicking it, edit it and just click save expecting that it respects your encoding. Sometimes it does, sometimes not. Sure, you can use Save as to be sure that it uses the encoding you want, but that was never neccessary before.

23 hours ago, jesu said:

Unfortunately, we still need to use ANSI in some files but sometimes (likely by notepad) that is replaced with UTF8.

I just took what the OP wrote and show a way to revert any file somehow changed from ANSI to UTF-8. I never said it is a silver bullet for all circumstances.

11 minutes ago, DelphiUdIT said:

Why someone would do this ?

Because it is the reverse of what Notepad in Windows 11 did to the files.

5 minutes ago, jesu said:

The fact is that we need to restore these files without loosing time doing it by hand.

Load the file with UTF-8 encoding and save it with ANSI encoding.

uses
  System.IOUtils;
  
...
  TFile.WriteAllText(FileName, TFile.ReadAllText(FileName, TEncoding.UTF8), TEncoding.ANSI);

If the files are too large to fit into memory, you need to work with different file names for input and output:

  var writer := TStreamWriter.Create(NewFileName, False, TEncoding.ANSI);
  try
    var reader := TStreamReader.Create(FileName, TEncoding.UTF8);
    try
      while not reader.EndOfStream do
        writer.WriteLine(reader.ReadLine);
    finally
      reader.Free;
    end;
  finally
    writer.Free;
  end;

Isn't the root problem where you read these strings in the wrong way and shouldn't it be handled right there?

Looks to me like some caching problem in the IDE. As you seem to have reproducible steps, you should file a bug report.

You can avoid that by setting MarkDisabledItem to False.

Add an event handler for OnEnableItem and set AEnabled := False;

If you can reproduce with a small sample database I suggest to file a bug report at https://qp.embarcadero.com/

According to the unit mentioned, the libraries named sqlite3_fde_x64.obj/sqlite3_fde_x86.obj are used. They come with Delphi and are located in subfolders of $(BDSLIB).

First, declare the message type in a common unit:

type
  TIntegerMessage = class(TMessage<Integer>);

Second, declare a TMessageListenerMethod in FormA handling that message type:

type
  TFormA = class(TForm)
    ...
  private
    procedure MyMessageHandler(const Sender: TObject; const M: TMessage);
  ...

procedure TFormA.MyMessageHandler(const Sender: TObject; const M: TMessage);
begin
  var msg := M as TIntegerMessage;
  // do something with the Integer you get from msg.Value
end;

Third, subscribe/unsubscribe to this message type in TFormA.FormCreate/FormDestroy:

procedure TFormA.FormCreate(Sender: TObject);
begin
  TMessageManager.DefaultManager.SubscribeToMessage(TIntegerMessage, MyMessageHandler);
end;

procedure TFormA.FormDestroy(Sender: TObject);
begin
  TMessageManager.DefaultManager.Unsubscribe(TIntegerMessage, MyMessageHandler);
end;

Finally, send the message in FormB:

begin
  ...
  TMessageManager.DefaultManager.SendMessage(Self, TIntegerMessage.Create(42));
  ...
end;

Note: Only the common unit with the type declaration has to be used by both form units. None of them needs to use the other form unit.

It seems to be reproducible reliably in the debugger, while without the debugger I can switch the size with or without errors and I was not able to identify a pattern, yet.

5 hours ago, Stompie said:

I would recommend installing ODBC18 on your dev environment, and the machine(s) you deploy to.

That would only help if you are using a Delphi version that supports it (i.e. Delphi 11.2 or higher).

See https://docwiki.embarcadero.com/RADStudio/Alexandria/en/11_Alexandria_-_Release_2#Updated_FireDAC_Drivers

Quote

FireDAC supports the latest Microsoft ODBC Driver for SQL Server (version 18).

The value of calculated fields are only stored for the current record. As soon as you move to another one, the field content is lost. Therefore you need to calculate the field value several times, which can slow down performance when the calculation needs some time. A solution is to cache these values.

16 minutes ago, Squall_FF8 said:

Does anybody knows why we have such weird execution order: Calc, AfterOpen, Calc?

Calculating fields is done on each record at several occasions. Any change to the current record, be it by navigating or switch to and from edit mode. AfterOpen is dataset based and when it is called, at least the first record is already loaded and all fields contain their values, including the calculated ones.

I would use a caching approach. In OnCalcFields try finding the ID in the dictionary like you already do. If not found, get the file size as you currently do in OnAfterOpen and add it to the dictionary.

1 hour ago, Anders Melander said:

And what's up with the use of pred? Since when did that become more readable than -1 ?

It survives the change from Integer to an enumeration type.

Not sure if this helps: Breakpoints are stored in the DSK file. Depending on whether you opened a project group or a standalone project (with that temporary project group created on the fly) this is the DSK file of the project group or the project. 

The TGlyph type being private and Glyph property being protected makes everything a bit cumbersome. Fortunately there is a trick to inject a message handler without subclassing.

type
  TEditButtonHelper = class helper for TEditButton
  public
    procedure LinkMessageHandler;
  end;

  TGlyphMessageHandler = class(TWinControlMessageHandler)
  protected
    function HandleMessage(var Message: TMessage): Boolean; override;
  end;

function TGlyphMessageHandler.HandleMessage(var Message: TMessage): Boolean;
begin
  var edt := TButtonedEdit(Control.Parent);
  case Message.Msg of
    WM_LBUTTONDOWN: edt.PasswordChar := #0;
    WM_LBUTTONUP: edt.PasswordChar := '*';
  end;
  Result := inherited;
end;

procedure TEditButtonHelper.LinkMessageHandler;
begin
  Glyph.InitMessageHandler(TGlyphMessageHandler);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  ButtonedEdit1.RightButton.LinkMessageHandler;
end;

The buttons of a TButtonedEdit are no controls, so there simply is no handle. Instead they provide an instance FGlyph of a private type TGlyph derived from TCustomControl, which handles the mouse events. This control has the edit control as parent.

Perhaps you can achieve your goal by deriving from TButtonControl and override GetEditButtonClass. This gives you access to the protected FGlyph and allows to replace it with a derived class implementing the requested behavior.

I am not aware of any setting. There is a setting in MMX that acts during navigation, but it doesn't show the behavior you see.

So, after making the issue go away, the key question is: Can you reproduce?

If Image1.Picture.Graphic is not of type TBitmap, referencing Image1.Picture.Bitmap will clear the current content and create an empty TBitmap.

47 minutes ago, Lajos Juhász said:

You can save the form, close all the projects and open the form the IDE will remove the reference to the datamodule and you will not see the pictures anymore.

I doubt that is correct. The datamodule dmSharedImages containing the image lists is part of GExpert and as long as GExpert is loaded in the IDE the datamodule exists and the references are resolved. The problem happens during runtime only.

BTW, 3rd party plugin developers should be aware of this and name their forms, frames and datamodules with in mind.