Alexander Halser

Thanks, Doug! Please tell me how to do that, and I'll be eternally grateful. Apple documentation says, that in order to revoke a certificate, you must contact product-security@apple.com. They find themselves not responsible and have redirected me to Apple Developer support. But support doesn't feel responsible either and suggested to contact product-security@apple.com. That email conversion has been going back and forth for more than a week now. No result yet. Maybe I should contact Embarcadero and ask them to build a new version of Delphi, that handles ambiguous certificates better. Or does it already? If Delphi did not specify the developer ID certificate by name, I could just use the existing one(s) and don't care about duplicates.

Funny you say that, Sherlock! I did. And they answered. Do you want a bonmot? Apple responded: Uhm. Additional certificates?

On MacOS when using a TMainMenu that integrates into the Apple system menu bar, sub-menus automatically close the entire menu when clicked, as illustrated in the screenshot. My configuration: Delphi 11 MacOS Big Sur Before I get into this really deep, could someone please confirm (or not) that this is a Delphi bug? Ideally with Delphi 11 plus an older version. Steps to reproduce the issue: Create a new project Drop a TMainMenu on the form Add several menu items with subitems No onclick handlers required, just go and run on MacOS This bug occurs on the native Apple menu only. The bug occurs with all menu items that represent a submenu. There's no such problem with TPopupMenu and there's no problem on Windows with TMainMenu at all.

Wow, you are right! Apple's Terminal app does have direct click handlers for some submenu items. Well, if Apple does it, it must be a feature and can't be a bug, can it? Now we've to find a way in Delphi to make this feature optional...

Update: Reformatted the Mac, installed maOS Big Sur, an older version of Xcode. Things now work as advertised with Delphi 11. But I am wondering what the underlying problem is and if anyone has managed to make this configuration work. The Mac is an M1 (2020), not an Intel machine. This configuration works: Delphi 11 plus November and January patch Hardware: M1 (2020) Mac running macOS Big Sur Xcode 13.2 Not working configuration: Delphi 11 plus November and January patch Hardware: M1 (2020) Mac running macOS Monterey Xcode 12.5.1 / 13.0 / 13.2 / 13.4.1

Following... I have the same problem with macOS and macOS ARM. Current config: Delphi 11 plus November and January patch MacOS Monterey 12.4 Xcode 13.4.1 (replace with 12.5.1, 13.0, you name it, all combinations tried)

Thread closed. My problem is almost identical with the one described here: iOS 15.1 - FMX - Delphi-PRAXiS [en] (delphipraxis.net) The switch from Delphi 10.4 to 11 helped to make some tiny progress and get the remote debugging to work. And the remote debugger tells me a bit more than question marks, it says: dyld[7422]: Library not loaded: \x90\x81\x17\x06-\xb4 Process MacTest (7422)

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.

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}