Leaderboard

That is much easier said than done. While increasing the font size inside a text editor control is usually no problem, doing that in a dialog may destroy the complete layout of that dialog. Having larger fonts in an TEdit will automatically increase the height of the edit, but not its width. A checkbox will even keep its height when the font size changes. Using a larger font inside inside a TRadioGroup also leads to unreadable text. What you suggest would require the scaling of all controls including scaling the complete form. That is exactly what the system scaling is made for. If you want larger fonts in MMX dialogs - increase your system scale. Short answer: No. There are other areas where my free time is probably better spent.

*sigh* i see no reasons for getting personal. There are different ways to look at and to solve a problem.

You're welcome - it is just a slightly improved version of what Aleksandr Sharahov already wrote years ago. Surprisingly they never used his purepascal code which compiles to almost the exact same code as the x86 asm version was doing. There are more than a dozen other improvements in the RTL that I have worked on - I cannot fix their compiler but I can certainly improve some suboptimal RTL code.

HTML Component Library, HTML Editor Library and HTML Report Library version 4.5 released. What's new: 1. RAD Studio 11 Alexandria support. 2. New THtMarkdownPanel component for displaying Markdown documents. 3. Improved Markdown support (tables, links, etc.) 4. Improved rending or large SVG images 5. Improved Flex support. 6. Improved handling of incorrect markup (tag order). 7. Added THtPanel.OnShowResizeHint event. 8. Added THtDocument.EmbedAllImages method for embedding images into document. 9. Added THtPanel.Script property for storing common scripts. 10. Added PrintScale parameter to Print method for scaling pages. 11. Added SplitBlocktoRoot method for splitting nested blocks (f.e. citation in emails). 12. Support for disablet attribute in inputs. 13. Added HighlightCheckedNodes property in THtVirtualXMLTree. 14. Improved scrolling of page with many input controls. 15. Added PNG encoding of pasted images for FMX. 16. New Editor event OnSurrogatePair. This event is called on second (low surrogate) char and when it returns true, default char processing is skipped. 17. SVG: added support for preserveAspectRatio with values none, meet and slice. 18. Faster rendering of large break-all blocks. 19. Support for type="number" in inputs. 20. Added Remove method to JQuery. 21. Addes support for attr!=value selector 22. Added support for summary and details elements. 23. DOCX to HTML conversion is now supported in Delphi 5 - 7. Fixed issues: https://delphihtmlcomponents.com/fixed45.html https://delphihtmlcomponents.com/

Indeed, I would never do that to MMX. Actually I would buy it myself if I would have any use for it that pays back. Usually I work for customers help them maintain or extend their existing software. Sometimes there are a couple of developers working on the project, sometimes I am the only one doing that. From all these dozens of customers I had in all these years only one had DevExpress and then only the grid. It doesn't matter what I think about DevExpress when the customer refuses to buy it. If the customer already uses DevExpress - no problem. So, if someone wants to write an MMX clone with the DevExpress Ultimate Layout Solution - go ahead.

Most things seem to use hh:mm. I was just trolling through Google and it looks like Oracle, PostgreSQL, Java all do. Python and C use good old-fashioned case sensitivity, with M for months and m for minutes. This seems to eliminate any ambiguity while still preserving the use of "m" for both months and minutes. Looks like case sensitivity 1, Delphi 0 here. EDIT: Today I learned that if you want to set the time to 00:00:00.00 UTC in PostgreSQL you can use "allballs" as the input string. I may need to file a Delphi feature request immediately....

I have to admit that I learned about hh:nn being the correct format quite late in my career. Nevertheless is it correct and logical. Using hh:mm just opens a can of ambiguity, makes the implementation more complex, error prone and slow. Unfortunately MS is not so consistent and also uses hh:mm. Note, that while TFormatSettings.Invariant uses the hh:nn format, TFormatSettings.Create(Locale:TLocalId) still falls back to hh:mm mimicking the MS style: if Result.ShortTimeFormat = '' then Result.ShortTimeFormat := TimePrefix + HourFormat + ':mm' + TimePostfix; if Result.LongTimeFormat = '' then Result.LongTimeFormat := TimePrefix + HourFormat + ':mm:ss' + TimePostfix; While we probably cannot drop hh:mm for staying compatible with Windows and older versions, using hh:nn where ever possible for unambiguousness is not that a bad idea.

Ideally it works out of the box, but that is rarely the case. First the VCL has a new default font Segoe UI 9pt, which is a bit larger than the previous. As the IDE makes also use of this, controls with ParentFont = true may be larger as expected. While labels usually handles that with their AutoSize property, CheckBoxes are more prone to clipping their text. (Side note: ParentFont = False doesn't work well either in the moment.) Icons are often the main barrier as you should provide different or at least larger sizes. The problem is using virtual ImageLists on the form or frame, where they are scaled properly, instead common image lists in some data module. Well, that's not the actual problem - that is keeping the old way working for the older Delphi versions, wich don't know about TVirtualImageList in the first place. One approach, when few forms are affected, can be stolen studied from the imagelist editor in PngComponents. It is also used in Project Magician and Selective Debugging, but for MMX I implemented a totally different approach, where explaining would go beyond scope here, I will be happy to help if you need some advice.

That is for C++, while in Delphi 32 Bit they are Extended. See Declared Constants

My guess is, in 64 bit Double and Extended are the same and constants are Double, but in 32 bit they are different and constants are Extended. The DoubleField matches the Double and Extended type as well as the Extended constant does, so the compiler doesn't know what to select.

Why is nobody else reporting this issue?

What the heck does this mean? People are trying to help you and the fact that you can't recognise it doesn't mean that they are unprofessional.

Did you watch the webinar today? In the webinar they spent some time talking about the new HIGH DPI settings. If you have a 4k monitor that's more like 27" vs. 55" and your Windows settings are designed to compensate for things, the IDE is may be ignoring the system's compensatory mechanism and doing things itself. I have a 4k 55" monitor and things look fine in Windows because everything is able to run at "normal" -- ie, uncompensated -- resolution. So it looks the same as 4 HD monitors running at HD DPI settings But on a small monitor, it's too tiny to read. I have to go into the Windows Settings and tell it to compensate. So the question about your SYSTEM SETTINGS IS 100% DEAD-ON. This is more about your system than Delphi because this NEW version of Delphi probably overrides whatever your Windows settings are. And there are settings in Delphi as well.

With Delphi 11 release a few minutes ago, MMX Code Explorer is already supporting it: Change log V15.0.44

I ended up combining the code of @chkaufmann and @Lars Fosdal plus added the always-disabled property. The end result fully supports VCL styles and looks awesome! The full code became: Unit uHeaderMenuItem; Interface Uses Vcl.Menus, Vcl.Graphics, WinApi.Windows, System.Classes; Type THeaderMenuItem = Class(TMenuItem) strict private Procedure SetEnabled(Const inEnabled: Boolean); Function GetEnabled: Boolean; protected Procedure AdvancedDrawItem(ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState; TopLevel: Boolean); Override; Procedure DoAdvancedDrawItem(Sender: TObject; ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState); Procedure Loaded; Override; Public Constructor Create(AOwner: TComponent); Override; published Property Enabled: Boolean Read GetEnabled Write SetEnabled; End; Implementation Uses Vcl.Themes, System.SysUtils; Procedure THeaderMenuItem.AdvancedDrawItem(ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState; TopLevel: Boolean); Begin Self.DoAdvancedDrawItem(Self, ACanvas, ARect, State); End; Constructor THeaderMenuItem.Create(AOwner: TComponent); Begin inherited; Self.Enabled := False; OnAdvancedDrawItem := DoAdvancedDrawItem; End; Procedure THeaderMenuItem.DoAdvancedDrawItem(Sender: TObject; ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState); Begin ACanvas.Brush.Color := TStyleManager.ActiveStyle.GetStyleColor(scPanelDisabled); ACanvas.FillRect(ARect); ACanvas.Font.Color := TStyleManager.ActiveStyle.GetStyleFontColor(sfWindowTextNormal); ACanvas.Font.Style := [fsBold]; ACanvas.TextRect(ARect, ARect.Left + 3, ARect.Top + 3, StripHotkey(Caption)); End; Function THeaderMenuItem.GetEnabled: Boolean; Begin Result := inherited Enabled; End; Procedure THeaderMenuItem.Loaded; Begin inherited; Self.Enabled := False; End; Procedure THeaderMenuItem.SetEnabled(Const inEnabled: Boolean); Begin inherited Enabled := False; End; End.

Thanks, now I see what you are after. The Vcl entry collects also the Vcl.ww* ones and the latter somewhat acts as a subgroup. Seems like the algorithm has to be fine tuned a bit. I will add that test case to the suite and see how I can make it green.

Thanks for all hints. I created a subclass of TMenuItem and did an override of the AdvancedDrawItem method. In addition I set Enabled=False. Themes are not support, but I don't have that anyway in my application. But so far it looks fine: procedure TMenuGroupItem.AdvancedDrawItem(ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState; TopLevel: Boolean); begin ACanvas.Brush.Color := TColors.Silver.Lighten(50); ACanvas.FillRect(ARect); ACanvas.Font.Color := TColors.SysWindowText; ACanvas.TextRect(ARect, ARect.Left + 3, ARect.Top + 3, StripHotkey(Caption)); end; Christian

That does not produce the requested effect. That is used for creating multi-column menus, not multi-group menus. This is the correct solution. Menus simply have no concept of groups, so "group headers" is accomplished by custom-drawing those menu items differently.

You can define the group names per project in MMX Properties - Project options: A single identifier is treated as a group prefix which has to be followed by a dot (like System, VCL, FireDAC). You can also use wildcards like Rz* for all units from Raize Components (KSVC). Unit names not covered in one of the schemes above can be listet in brackets. This is the setting for MMX itself: (ToolsApi,DesignIntf,DCCStrs,DockForm,TabDock);Winapi;System.Win;System;Xml;Vcl;VirtualTrees*;Rz*;Tb*;Png*;MMX The settings are stored in the dproj file.