rvk

No, unfortunately TWebBrowser.Document isn't available for FMX. https://stackoverflow.com/a/41853823/1037511

Ah, ok. I thought the default for DoubleBuffered was true. But I am probably mistaken (it is true in Lazarus unless in a remote session but apparently not in Delphi).

You didn't set DoubleBuffering to false for the TFrame itself (at least not in the code I saw). So if there (for TFrame) it is still true, then SingleBufferingInRemoteSessions = false would make the difference.

Woops, sorry. The Application.SingleBufferingInRemoteSessions is true as default. You should try to set it to false so the RDP acts the same as without RDP regarding doublebuffering. http://docwiki.embarcadero.com/Libraries/Alexandria/en/Vcl.Forms.TApplication.SingleBufferingInRemoteSessions

Yes. So you could set SingleBufferingInRemoteSessions to true to test if enabling DoubleBuffering in RDP would help. (turning on DoubleBuffering manually doesn't have effect if SingleBufferingInRemoteSessions is still set to false) If it doesn't help, then it must be something else.

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Double-buffering_and_Remote_Connections

PS. You testproject in your openingspost works for me (Compiled on Delphi 10.2, Windows 10 and RDP'ing to a Windows 10 Hyper-V). Panel show solid (without memo1 bleeding through).

Could be related to this: WS_EX_LAYERED window appearing invisible over RDP Or with Alpha blending https://duckmaestro.com/2010/06/06/per-pixel-alpha-blending-in-win32-desktop-applications/

Weird, I would expect just the opposite (solid in rdp and transparent locally). What are the settings under the Experience tab in your RDP connection? Ser it to highest speed and disable bitmap caching and see if that helps.

The real question is: Does the program REALLY access those IPs? It could be that virustotal just analyses the code and sees some unreachable code that could access those IPs. Maybe it's never called. The only way to be sure is to check it yourself (as mentioned before).

Wait... did I really overlook that file... Aaaargh. Yes, it's in the root.

Why is the date of the files on Fulgan updated each night? Also, there seem to be trickling new versions in there occasionally. Maybe a readme file there pointing to the new official spot (or at least stating it is decommissioned) would make that more clear.

Yeah, I never used those from slprowen. They only provide an executable with god-knows-what build in. Quote from this site https://wiki.overbyte.eu/wiki/index.php/ICS_Download The indy.fulgan.com ones (same as the one you now use) never gave me problems.

Where did you get the openssl-1.0.2u dlls from? As I understand it there could be version with and without the dependencies to those Microsoft DLLs. From https://wiki.openssl.org/index.php/Binaries (the indy.fulgan.com ones shouldn't have any dependency):

Maybe its the default font but it definitely displayed differently (look at the capitol G which is different). So maybe there is still some font substitution going on. You can first look in this registry entry to see if that font is substituted. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes Btw. You showed the font for a tlabel. But if the parentfont prop is true, it will take the font from the form. And it could be that for that the screen.font is used which might use the default menu font from windows. If that's the case you might want to do a Application.DefaultFont.Name := 'MS Sans Serif'; (or other font) before creating any forms in your .dpr).