Alexander Halser

I've come across a problem with FMX apps and high-contrast Windows themes. The automatic window scaling doesn't work in this case. I wonder if this is a known problem and if yes, if it is Delphi related or Windows related? You should be able to reproduce this in the following way: 1) Create an FMX app with a simple form 2) Make the app per-monitor-dpi-aware-v2 3) Run it normally on Windows 10 on a monitor with more than 96 dpi (scaling > 100%) 4) Switch to a high-contrast theme, repeat step (3) 5) On Windows 7 the same effect can be observed with a "basic" vs. a "classic" theme Delphi versions: tested with Delphi 10.1 and 10.4 (same result). Not tested with Delphi 11. My observations: On Win10 with a regular theme, the app behaves as it should. When started on a monitor with 96 dpi, Form1.Handle.Scale = 1 (as expected). Started from a monitor with 192 dpi (200%), Form1.Handle.Scale = 2, as expected. Moving between monitors with different resolution/scaling instantly changes the scale. On Win10 with a high-contrast theme, scaling does no longer work. When started from a monitor with 192 dpi, the form stays at its original size, as if it never received a scaling message. Moving the app between monitors does not change the scale. Instead, the app stays at its initial size (always the equivalent of 96 dpi). Same thing happens on Windows 7 with a 125% system scaling (one monitor only): with a regular Windows 7 theme, the app starts scaled with 125%, as expected. When switching Win7 to a "classic" theme (or high-contrast, for that matter), no scaling occurs. A very similar VCL app, also per-monitor-dpi-aware-v2, does scale properly in all situations. It's FMX only. Here's a screenshot of the FMX app on Win10 and Win7:

Update: it is/was a known problem at Embarcadero and the bug has obviously been fixed with Delphi 11. Thread closed.

This is an implementation of the eWriter help format as a replacement for HTML Help (.chm) files in Delphi applications. EWriter eBooks are the modern alternative to the obsolete CHM format for local application help. They offer full support for context-sensitive help and file links. They combine the benefits of CHM and WebHelp and eliminate the disadvantages of both. To create eWriter eBooks, you can either use our freeware HTML compiler eWriter Creator or our commercial help authoring tool Help+Manual, which creates this format out of the box. The package includes the unit Vcl.EwriterHelpViewer.pas which implements support for the eWriter help format in Delphi’s help system. Applications currently using CHM files for application help can switch to eWriter help with basically no changes. The distributable eWriter viewer is included. The package is available from the download link below and from the GetIt Package Manager. Alternative download link: https://www.helpandmanual.com/downloads_delphi.html Compatiblity: Delphi XE upwards Alexander Halser EC Software GmbH www.helpandmanual.com

I struggled with TEdgeBrowser and the updated TWebBrowser that comes with 10.4. TEdgeBrowser did not work at all, like you experienced. TWebBrowser still just worked in IE11 fallback mode. Latest Windows update and MS Edge/Chromium is installed. What effectively solved the issue for me was to install the WebView2 runtime: WebView2 - Microsoft Edge Developer After a couple of tests, it seems to me that the runtime is also required on the client computers. It is not sufficient to just deploy WebView2Loader.dll with the application, but the target system requires the WebView2 runtime as well. Which is quite unfortunate, because that needs admin rights to install. I wonder when Microsoft will ship an MS Edge/Chromium with Windows, that comes with the runtime to support an embedded TEdgeBrowser.

This does not really help, but I can confirm that TWebBrowser can not (or no longer?) print PDF files. Clicking the print button that's shown as an overlay does nothing. When invoking the print command manually with WebBrowser1.ControlInterface.ExecWB(OLECMDID_PRINTPREVIEW, OLECMDEXECOPT_DONTPROMPTUSER, vIn, vOut) ; it raises the error message "Trying to revoke a drop target that has not been registered". Never seen this before. The missing print function applies to PDF files only. Regular HTML files and websites do work as advertised.

I am using TEmbeddedWB (an extended version of TWebBrowser, the "latest" from GitHub from 2011) in a VCL application, where it works just fine. The very same code compiled with 64 bit, however, crashes on some pages/scripts. The crash comes from C:\Windows\System32\jscript9.dll and reads: First chance exception at $00007FFF99D9840. Exception Class $C00000090 with message "c00000090 FLOAT_INVALID_OPERATION' It can be duplicated with a very simple test app in Delphi 10.1 or 10.3. If I use a standard TWebBrowser instead of TEmbeddedWB, it runs fine both as 32 and 64 bit. So I assume it is some declaration issue in one of the old units of TEmbeddedWB, that are not compatible with 64 bit. Any suggestions what to look for in the code?

Have a look at my NHunspell implementation (mentioned above as https://www.helpandmanual.com/downloads_delphi.html, but it's on SourceForge as well): https://sourceforge.net/projects/nhunspelldelphi/files/ It is a wrapper for NHunspell for Delphi 2007 up to the latest versions. And it includes a wrapper class for Addict v4 dictionaries. Hunspell is great, because it's open source and can use numerous dictionaries from OpenOffice. But Hunspell alone is missing a parser for the classes/controls used by many Delphi developers. Like a TRichview, just to name an example. The Addict spell checker is great, because it is a solid spelling checker with a full-fledged parser, has been around for quite a while and it enjoys support for almost every Delphi control you can think of. Just the dictionaries delivered with Addict were never really good. My goal back then was to combine the two, without having to rewrite everything spelling-check related. We keep using Addict as the spelling checker for everything it was used before. But we don't use the dictionaries. The component comes with an ad3MainDictionary.pas unit (which is, in fact, for Addict 4) and implements a new TMainDictionary (the Addict dictionary class), which redirects the generic functions to Hunspell. The unit needs to replace the original unit from Addict, or take precedence in your search path. The main dicts can be mixed with custom user-defined dictionaries from Addict and the spelling check function is fully transparent. The wrapper has been approved by Addictive Software for inclusion into the open source distribution, because this part of the package is actually not fully open. What it does Implements Hunspell for Delphi 2007 and up. Takes .OXT files as dictionaries, no need to unzip them. A simple zip reader and XML parser is part of the distribution. Supports spelling and hyphenation dictionaries (no Thesaurus) Optionally introduces a TMainDictionary wrapper to use it with the Addict Spelling checker So, if you have been using Addict (you need an Addict license, to use the Addict wrapper) you have the best of both worlds with this implementation. You can use Addict as your spell check engine without many changes, but run it with OpenOffice dictionaries. The hyphenation part is separate from Addict and needs to be applied manually. All the control parsers that were made for Addict, however, should be working fine. I haven't bothered to update the component on SourceForge. It has received a few internal tweaks in last couple of years - mostly strange OXT configurations, that we have come across. If you are going to use it, please PM me for an update.

That part was missing in the ~WB version. Must have been added in more recent versions of SHDocVw.pas.

Thank you! This has indeed solved the issue. initialization {$IFDEF WIN64} System.Math.SetExceptionMask(exAllArithmeticExceptions); {$ENDIF}