use the system highlight color

[Brannon]

A few minor nitpicks in version 7:

The installer with style "modern dynamic windows11" doesn't actually use the highlight color specified for the Windows theme. It always uses blue instead. It should use the system theme colors as queried from the system.

The color of the (absent) border around the license text is different from the border around the text box on the next page (that shows the selected installation folder). The license text control might also benefit from a bit of padding inside.

I have an rtf file that contains my license text. The rtf file contains no coloring information at all. When this is displayed via wine (version 11.5) on Linux with the "modern dynamic windows11" style, the license text is black on black. It seems to look okay (showing white text) on Windows.

[Martijn Laan]

Hi,

Thanks for the feedback. I think all of it actually applies to version 6 as well.

• A dynamic highlight color is unfortunately not supported by the VCL Styles system we use AFAIK.
• Do you have a screenshot explaining what you mean about the border colors?
• I think the padding might be controlled by the RTF, but am not sure.
• The code we use to handle RTF colors when a style is active can be found at https://github.com/jrsoftware/issrc/blob/e582551b4789b976927fa35679ffe60535a6c8d0/Components/RichEditViewer.pas#L485
  Perhaps wine does not support EM_GETOLEINTERFACE? I suppose it could fallback to our previous implementation, which simply removed all foreground coloring. Not ideal but would avoid black on black.

Greetings,
Martijn

Op 25-3-2026 om 16:32 schreef Brannon:

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/953c164d-7ae6-466e-8a3c-3238e6358a7en%40googlegroups.com.

[Brannon]

It seems you can use StyleServices.GetSystemColor to read out the current system colors. You would then apply those to your theme or controls. There's some example here: https://support.tmssoftware.com/t/new-delphi-style-system/20774 . I haven't looked into it deeply.

About the border, I just mean that there isn't a border or it's not visible in the dark theme on the license text box.

So the RecolorAutoForegroundText method is trying to override any colors that might be included in the rich text document? Maybe it would work to strip those tags from the RTF before displaying it instead? Or maybe we just warn the user at ISS compilation time that their RTF has colors in it that might conflict with the dynamic theme?

You're probably right about EM_GETOLEINTERFACE being not fully supported on Wine. That seems scary.

[Martijn Laan]

Hi,

Op 25-3-2026 om 16:50 schreef 'Martijn Laan' via innosetup:

The code we use to handle RTF colors when a style is active can be found at https://github.com/jrsoftware/issrc/blob/e582551b4789b976927fa35679ffe60535a6c8d0/Components/RichEditViewer.pas#L485
Perhaps wine does not support EM_GETOLEINTERFACE? I suppose it could fallback to our previous implementation, which simply removed all foreground coloring. Not ideal but would avoid black on black.

I investigated this a bit more, and while Wine does support EM_GETOLEINTERFACE, it does not support navigating by unit tomCharFormat, which is what we do. You can see the FIXME in the Wine code in here: https://gitlab.winehq.org/wine/wine/-/raw/master/dlls/riched20/richole.c#:~:text=textrange_moveend

So while I did not actually run Wine yet, I do think this is the core issue. Can maybe workaround it by navigating by unit tomCharacter instead.

Greetings,
Martijn

[Martijn Laan]

Op 21-4-2026 om 21:23 schreef Martijn Laan:

I investigated this a bit more, and while Wine does support EM_GETOLEINTERFACE, it does not support navigating by unit tomCharFormat, which is what we do. You can see the FIXME in the Wine code in here: https://gitlab.winehq.org/wine/wine/-/raw/master/dlls/riched20/richole.c#:~:text=textrange_moveend

So while I did not actually run Wine yet, I do think this is the core issue. Can maybe workaround it by navigating by unit tomCharacter instead.

So, I looked at it some more, Wine's RichEdit OLE interface implementation has 3 bugs which prevent our code from working. None of these bugs are present in actual Windows.

1. the tomCharFormat issue mentioned above.
2. MoveEnd returns a Delta of 1 even when the true Delta is 0, happens when the range is at the end.
3. GetForeColor doesn't honor CFE_AUTOCOLOR, meaning it never returns the special tomAutoColor color.

What I did now is revert to our previous EM_GETCHARFORMAT/EM_SETCHARFORMAT based implementation. This works with both Wine and Windows. Little bit less efficient but should not be noticeable at all.

Will look into putting it into IS 6 as well.

Greetings,
Martijn

Wine example: