Uwe Raabe

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;

That is even mentioned in the docs (https://docwiki.embarcadero.com/RADStudio/Athens/en/Variant_Types_(Delphi)#Variants_in_Expressions)

Indeed, it does...

I tried with Delphi 12.3 using SQL Server 2019. The Hour field is definitely time(7) - I used the CREATE TABLE command given by you.

GetIt only installs in the current IDE. Not in any other registry node nor in the 64-bit one. Nevertheless, the packages exist and you can simply add them via Components - Install packages.

Unfortunately not for every patch.

I wonder if beta testing for the patches would help here.

Try with external MSBuild in the project options and select x64 as preferred architecture. Key is to use the 64-bit compiler versions from the bin64 folder. The target platform is almost irrelevant. Only bcc64x got an update with the April patch.

Sounds reasonable:

It also works at runtime. In that case you need to set the FieldOptions.AutoCreateMode of the query to acCombineAlways to create the dynamic fields and the FieldOptions.PositionMode to poFieldNo to get the same order as before.

Works perfectly over here with static fields. Probably something in your setup.

Well, it does not do that in all of my queries and those of my customers. Can you also show the table definition of CD_Main (the CREATE TABLE command)?

Can you show the actual SQL for that query?