PeterPanettone

I have YOU to thank for such an ingenious product as GExperts! I could not take over the maintenance of GExperts. YOU are the leading expert for GExperts!

Dear Thomas, you are completely right! But all these DPI problems can be OVERRIDDEN by using an optimal LAYOUT. The logical error is to focus only on one issue (the DPI settings) while ignoring the broader context of responsive design and layout adaptability.

I use Delphi 12.2 in Windows 11 and have just now downloaded and compiled version r-4418: 1. you should not trust the GExperts users to use the same DPI settings as you when they compile the GExperts source code. 2. you should prioritize LAYOUT over blindly trusting that your DPI settings will work for the users when they compile the GExperts source code. Following rule #2, I have now moved the main dialog buttons down to the bottom into a separate panel, which creates a more logical layout: In the next step, I will adjust the layout logic for multiple properties.

Dear Thomas! Can you please post a screenshot with multiple properties? Thank you! And a happy new year! 🎈🙋‍♂️

Hello Thomas, Thanks for the information. The GExperts Rename Component expert is indeed useful when changing only the name. However, with multiple properties, the layout is broken and inconsistent:

I want to achieve this design time automation: Whenever a new object is created (either from the Palette or by pasting an object from the clipboard), the Quick Edit dialog for the new object is automatically shown. Is there a way to achieve this with GExperts?

Having flexible UI options is always a good thing. Thank you!

Better display of tabs in the SourceCode editor (OPTIONAL): 1. Marking of the MainForm unit in bold font 2. Marking files that do not belong to the current project in italics This would lead to more visual consistency and transparency in the presentation of the tabs in the SourceCode editor. What do you think? Thanks to everyone for taking part in this BRAIN TEST!

Another solution could be to subclass TRichEdit and then (temporarily) suppress the TAB character, but it's not worth the effort.

Thanks for the information.

Using KeyPreview, I have even tried the following trick: procedure TformTextEditor.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); begin if (Key = Ord('I')) and (Shift = [ssCtrl]) then begin CodeSite.Send('TformTextEditor.FormKeyDown: '); Key := 255; end end; And then in RichEditKeyDown: if (Key = 255) and (Shift = [ssCtrl]) then begin CodeSite.Send('RichEditKeyDown: '); Key := 0; // does not prevent TAB output! end

Even when KeyPreview = True, setting Key := 0; in FormKeyDown does not prevent this strange effect: procedure TformTextEditor.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); begin if (Key = Ord('I')) and (Shift = [ssCtrl]) then begin CodeSite.Send('TformTextEditor.FormKeyDown: '); Key := 0; end end;

At run-time, select any text in a TRichEdit and press CTRL+I: The selected text will be replaced by a TAB "character," which has the same effect as pressing the TAB key. BTW, the same effect occurs in Notepad. Is there a way to prevent this? Delphi 12.2 Windows 11 x64

To summarize, MMX is an extremely valuable and flexible addition to the Delphi developer's toolkit. I like the fact that you can switch off the bookmarks if you don't need them. Perhaps it would be helpful if the bookmarks were switched off by default during the initial installation.

It's nice to hear that someone uses it.