Uwe Raabe

Not sure if I get you right, as managing the file version information is usually done in Project Options: https://docwiki.embarcadero.com/RADStudio/Athens/en/Version_Info

No, the actual components don't have to be derived from TSelectionEditor. That would probably be near to impossible, as it would require to use design-time code in the application. Instead you need to register a TSelectionEditor descendant for each of these components and implement the RequiresUnits as appropriate.

I'd like to ask for more details about the term early in this context. Is this targeting the initialization sections of some units or more the code in the dpr begin end section? I admit that I often fell into the trap to put too much code into the initialization section, but I found that it heavily reduces the possibility to tweak the behavior based on a configuration or on a per project basis in case these units were used in several projects. That was a driving force for the invention of Cmon.Initializing. While it is still a long way to get all (probably better most of) my projects suffering from the above drawback, this approach is almost mandatory for new projects now. As a couple of units of CmonLib make use of this, one can find some hints for usage in the examples (still successfully procrastinating the CmonLib documentation, I know). Let me show a simple example from Cmon.Messaging.Dialogs.Vcl. This is how it would be written the old way: var Instance: TDlgMessageHandlerVcl = nil; initialization Instance := TDlgMessageHandlerVcl.Create; finalization Instance.Free; end. As a result, simply using this unit will create the instance, which registers itself catching the corresponding messages. And this how it looks making use of Cmon.Initializing: var Instance: TDlgMessageHandlerVcl = nil; { will be called in Application.Initialize after all other initialization code has been executed } procedure InitHandler; begin if TDlgMessage.AutoRegisterHandler and TDlgMessageHandlerVcl.AutoRegisterHandler then Instance := TDlgMessageHandlerVcl.Create; end; initialization TDlgMessageHandlerVcl.AutoRegisterHandler := True; TInitialize.AddInitProc(InitHandler); finalization Instance.Free; end. Now creating the instance will take place during Application.Initialize, which allows us to write some code tweak the behavior. As of my personal preference I put all this pre-initialize code in s similar named procedure, called immediately before: program DialogsDemoVCL; uses Vcl.Forms, Cmon.Messaging.Dialogs.Vcl, Main.VclForm in 'Main.VclForm.pas' {MainForm}, Utilities in 'Utilities.pas'; {$R *.res} procedure PreInitialize; begin { Per default using Cmon.Messaging.Dialogs.Vcl will automatically register the containing message handler during Application.Initialize. To optionally disable auto registering of all DlgMessage handlers this is one place to do. You need to add Cmon.Messaging to the uses to make it compile. } // TDlgMessage.AutoRegisterHandler := False; { You can as well disable automatic registration of indivudual handlers. That implies to leave the corresponding setting above at True of course. } // TDlgMessageHandlerVcl.AutoRegisterHandler := False; end; begin PreInitialize; Application.Initialize; Application.MainFormOnTaskbar := True; Application.CreateForm(TMainForm, MainForm); Application.Run; end. You can find a similar approach in Cmon.Messaging.Logging.TextFile

Can you compare the dsk files for the group and the single projects? Can you spot something fishy?

Can you show some code - even when ugly?

What hinders you to declare your own types for that? Then you can write your event handler methods just like before. type TFooProtocol = TCustomProtocol<TFooMsg>; TBarProtocol = TCustomProtocol<TBarMsg>;

There are some constants declared in System.pas telling the history: OlderLocaleOverrideKey = 'Software\Borland\Delphi\Locales'; // do not localize OldLocaleOverrideKey = 'Software\Borland\Locales'; // do not localize NewLocaleOverrideKey = 'Software\CodeGear\Locales'; // do not localize NewerLocaleOverrideKey = 'Software\Embarcadero\Locales'; // do not localize

You can multi-select all design packages and install them at once.

Should already be fixed in the current version.

You somehow misread my advice. The DefaultDrawColumnCell call should be in the non-boolean case, where all non-boolean fields are handled: procedure TForm1.DBGrid1DrawColumnCell(Sender: TObject; const Rect: TRect; DataCol: Integer; Column: TColumn; State: TGridDrawState); const CtrlState: array[Boolean] of integer = (DFCS_BUTTONCHECK, DFCS_BUTTONCHECK or DFCS_CHECKED) ; begin if (Column.Field.DataType=ftBoolean) then begin DBGrid1.Canvas.FillRect(Rect) ; if (VarIsNull(Column.Field.Value)) then DrawFrameControl(DBGrid1.Canvas.Handle,Rect, DFC_BUTTON, DFCS_BUTTONCHECK or DFCS_INACTIVE) else DrawFrameControl(DBGrid1.Canvas.Handle,Rect, DFC_BUTTON, CtrlState[Column.Field.AsBoolean]); end else DBGrid1.DefaultDrawColumnCell(Rect, DataCol, Column, State); end;

Make sure that the DefaultDrawing property of the grid is False and add a DefaultDrawColumnCell(Rect, DataCol, Column, State); call in your OnDrawColumnCell event handler for the non-boolean field case:

Could it be that the quote contains something like Premium Update Subscription? If yes, ask for removing that. Sales are forced to add that when sending the first quote.

Also in the Project menu the Information for Project gives you the file size (and some more possibly useful information). It is not the same as to display it directly in the compile dialog, but some people (like myself) opt to automatically close it on success.

Delphi 11.3 is running in DPI aware mode per default. You have basically two options: in the High DPI designer options switch to automatic mode. That will scale the form according to the current Windows scaling and change all the positions and sizes in your DFMs start the IDE in DPI unaware mode. There should be a suitable entry in your Windows start menu.

This kind of approach is usually seen when types previously declared in that unit have been moved to another one. Otherwise existing code would no longer compile. My personal preference would be to add all needed units to the uses clause. As always there might be exceptions with valid reasons.

That won't explain the different appearance of the header. Nevertheless, way too less information to find the cause.

What Delphi version are you using? TBitBtn supports Images since Delphi 10.4. If by any chance you are able to use one of the more recent Delphi versions, I suggest to use the image list approach. It is way easier to maintain, especially when you plan to support High DPI in the future.

Probably depends on the Delphi version you are using.

If you use the Glyph property of TBitBtn, this will indeed be quite tedious. The preferred way is to use the Images property to assign an image list and set the ImageIndex/ImageName and DisabledImageIndex/DisabledImageName to the proper icon. There are also such properties for the Hot, Pressed and Selected states.

Actually it contains both:

A workaround would be to declare the array as a constant or create a dynamic array on the fly: for I in TArray<Integer>.Create(45, 30, 15) do

AFAIK, this command is only available from the context menu of the form designer.

While I have the same problem when using alternative registry keys (instead of BDS), I thought of creating a separate management tool, but as ever so often spare time is limited and valuable.

This usually happens when MMX has been installed for all users, i.e. as an admin. That will use HKLM for the Experts entry, which will be copied to HKCU when a user starts Delphi. As the installer didn't add these registry entries, it refuses to remove them when uninstalling (this is standard behavior of InnoSetup). Actually, these kind of quirks are the reason why Install for me only is recommended. If you are the only user at the system it doesn't matter at all and if you are not, each user will have its own copy of MMX installed (they can even have different versions). I always try to clean up as neatly as possible when uninstalling, but I didn't find a reliable way to do that without jumping through hoops with the registry and several user folders.

You can always configure a different (or even no) shortcut to any MMX command. See MMX properties -> Key bindings.