Uwe Raabe

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

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.

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.

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.

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.

Probably, yes.

Wrong thread? What does [ref] attribute actually dows

While the inconsistency is obvious, there might be different opinions about which behavior is correct. One can argue that the local variable case is older and thus takes precedence. That would also take care of existing code staying compatible. Throwing an error on both cases would emphasize the type safety, but may cause some user complaints.

The problem is inconsistency, as it compiles when f is declared as a local variable. Also see the example in the comment of Jost Riedel in the mentioned QP issue. procedure X(i: Integer); begin end; procedure Y1; var f: TFunc<Integer>; begin X(f); // compiles end; procedure Y2; begin var f: TFunc<Integer>; X(f); // fails end;