Jump to content

rvk

Members
 View Profile  See their activity

  • Content Count

    126

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by rvk

  2. Posted

    15 minutes ago, aehimself said:

    That means it is using the default, which is False for DoubleBuffering.

    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).

     

  3. Posted

    16 minutes ago, aehimself said:

    The only question which I have remaining - if DoubleBuffered is false everywhere in the test application, how come enforcing single buffering makes a difference?

    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.

     

  4. Posted

    20 minutes ago, aehimself said:

    Even if DoubleBuffered is on for the frame and the form, and Application.SingleBufferingInRemoteSessions is true

    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

     

    • Thanks 1

  5. Posted

    On 1/8/2024 at 9:15 PM, aehimself said:

    Interesting read! Do I understand it correctly that if you do NOT override anything, themed and un-themed controls do not use double buffering (even if set in object inspector) if a remote session is detected?

     

    If yes, it means we can completely exclude double buffering as a potentional suspect for this particular issue.

    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.

     

    • Like 1

  9. Posted

    3 hours ago, aehimself said:

    Locally I receive a solid form while through RDP everything is transparent, revealing the component underneath:

    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.

     

     

     

  10. Posted

    1 hour ago, everybyte said:

    A simple console application (compiled in Delphi CE 10.4) that does a single console WriteLn when checked in virustotal.com sandbox is seen accessing three IP addresses:

    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).

     

  12. Posted

    20 minutes ago, Remy Lebeau said:

    OK, well... :classic_tongue: The fulgan mirror has been decommissioned for some time now, the GitHub repo is the official spot now.

    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.

     

  13. Posted

    10 minutes ago, Stompie said:

    If I remember correctly, I followed the instructions provided by Embarcadero: https://docwiki.embarcadero.com/RADStudio/Seattle/en/OpenSSL#32-bit_and_64-bit_Windows and I used option 1 to get the dlls, so they came from https://slproweb.com/products/Win32OpenSSL.html back when the 1.0.2 where available 

    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

    Quote

    OpenSSL website also links to Win32OpenSSL website providing another build of Win32 DLL binaries. Note note that unlike the builds above builds on that site may have dependencies on Visual C++ 2008 Redistributables (to keep dll files smaller) so make sure you include all the required (and correct) redistributable files in your software installation. You probably don't have to care about that if you use binaries above at the cost of slightly larger DLLs. Also note that site does not keep archives of older versions so you may want to watch their page if you prefer their binaries.

     

    The indy.fulgan.com ones (same as the one you now use) never gave me problems.

     

  14. Posted

    20 minutes ago, Stompie said:

    I had the same issue on a new Windows 2016 build server with the openssl-1.0.2u dll in my application folder 

    
Could not load SSL library.
WhichFailedToLoad: "Failed to load libeay32.dll."
GetLastError: 126 - "ERROR_MOD_NOT_FOUND"

    Using ProcessMonitor I was able to find out that msvcp120.dll was not found on the host system,
    so I had to install the latest "Visual Studio 2013 (VC++ 12.0)"
    https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-studio-2013-vc-120

     

    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):

    Quote

    Pre-compiled Win32/64 libraries without external dependencies to the Microsoft Visual Studio Runtime DLLs, except for the system provided msvcrt.dll.

     

  15. Posted

    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).

     

  17. Posted

    31 minutes ago, Fr0sT.Brutal said:

    Nice property, I wasn't aware of it. But it's D2009+

    Yes.

     

    What font does Delphi 7 use. Always the font in which it is designed (font property of the form)?

     

    In that case... what font did you set in the form property? If that font isn't available anymore in Windows 11, this could also explain a lot.

     

    So specify a font which still exists on W11 or install the font used in D7.

     

  18. Posted

    You can also check the default system font size in Windows (do not choose Large letters etc.).

     

    But you can begin by setting a default static font and size at startup in Delphi. Otherwise a system font is taken at startup which can be different on every system. And some components get resized according to the fontsize).

     

    Application.DefaultFont

    See https://www.delphipower.xyz/handbook_2009/default_fonts_for_application_and_screen_global_objects.html

     

    But it's much easier to do this in a small test program than doing this in your final program.

     

  19. Posted

    4 hours ago, jsen262 said:

    both of them has been set 100% on scale in windows display setting.

    That would be my first suggestion too... different dpi settings.

    Weird that's not the case here. Looking at the screenshots there is really something going on with different font/dpi settings.

     

    Do you include a manifest.txt in your program/resources?

    Is this a designed form (not created at runtime)? And is it designed on 100% 96dpi (pixelsperinch)?

    Is your developing machine Windows 10? With Delphi 7?

     

    Scaled etc. shouldn't matter if both are on 100% 96 dpi. In that case Delphi 7 also shouldn't matter because it doesn't do anything if it's just at 100%.

     

    Try to make a small test program with just some tlabels and tpanels and see if you that also goes wrong.

     

  22. Posted

    3 minutes ago, Clément said:

    My best guess is that windows zip uses all 3 files combined to achieve a better compression result.

    Yes, That's what I expected.

    I'm not sure if you can tinker with the buffer settings of TZipForge to achieve the same result.

    (maybe the bigger the buffer, the faster it sees there is some repetition.)

     

    Did you also test CompressionMode 5? (CompressionMode <> CompressionLevel).

     

    BTW. Just a stupid question... but did you unzip your Windows-zip to see if the result is correct :classic_happy:

  23. Posted

    10 minutes ago, Clément said:

    I downloaded the personal version an yet... the same results...

    What happens if you set the CompressionMode to 5?

     

    If it's still the same size, can you test with the file from http://mattmahoney.net/dc/textdata.html

    In that case we are talking about the same file.

    It could be that your file is extra compressible by the way Windows does it.

     

    And if it still does not compare, you might want to post some code.

     

  25. Posted

    7 minutes ago, Clément said:

    I'm using zip forge clMax to try to get as close as possible to Windows10_X64 size.

    That's with CompressionLevel to clMax. What was the CompressionMode and Zip64Mode setting?

     

    If that is the maximum TZipForge can do I guess you can write that one off.

     

×