Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. DPI issue when calling C# from C++

DPI issue when calling C# from C++

Scheduled Pinned Locked Moved C#
csharphelpc++dotnetannouncement
3 Posts 2 Posters 3 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    JudyL_MD
    wrote on last edited by
    #1

    I'm putting this in C# since it's an issue with initializing NET... I have a WinForm DLL that is written to be DPI-aware. It is called from both C# and C-based executables. There is an intermediate mixed-mode C / CLR / C# DLL between the executable and the Winform DLL that calls from C to Managed C++ to C# to launch the WinForm DLL. Both the C and the C# exe are also DPI-aware (as appropriate for their language) and both display correctly. Here's the logic flow. C or C# exe: - calls into the intermediate's cdecl entry point using the usual LoadLibrary / GetProcAddress mechanism intermediate mixed-mode DLL: - C entry point makes a call to an internal CLR function - CLR function marshals the parameters, does a gcnew on a C# class and calls its single member function - C# member function:

    Assembly targetAssembly = Assembly.Load (File.ReadAllBytes ("path to winform dll");
    Type startType = targetAssembly.GetType ("startupNameSpace.startupClass", true);
    object startLib = startType.InvokeMember ("", BindingFlags.CreateInstance, null, null, new object[0]);
    startType.InvokeMember ("startupMethod", BindingFlags.InvokeMethod, null, startLib, new object[] { marshalled parameters } );

    WinformDll: - startupNamespace.startupClass is NOT a form, just a plain C# class - startupMethod creates a parameterized thread, sets the apartment state to STA and starts the thread passing the marshalled parameters - the thread instantiates the first WinForm class with the parameters and calls ShowDialog So, here's the problem. When run from a C# exe, the DPI logic works correctly. I have a C#exename.exe.config file in the same directory with the exe that contains a "startup" section with my framework version number and a "System.Windows.Forms.ApplicationConfigurationSection" section containg the DpiAwareness key with a value of PerMonitorV2. When run from a C exe, the WinForm display is incorrect in the exact places where I have my DPI-handling logic. It's obvious from the display that the property DeviceDpi is incorrect for every form. The research I've done leads me to believe that the .NET environment created to run my winform assembly is missing the dpi awareness flag that is set in the config for the C# exe. I've tried adding a config file with all the different name permuations using the C exe name, the intermediate dll name, the Winform dll name, "exe" and "dll". Nothing is picked up by the NET subsys

    Richard Andrew x64R 1 Reply Last reply
    0
    • J JudyL_MD

      I'm putting this in C# since it's an issue with initializing NET... I have a WinForm DLL that is written to be DPI-aware. It is called from both C# and C-based executables. There is an intermediate mixed-mode C / CLR / C# DLL between the executable and the Winform DLL that calls from C to Managed C++ to C# to launch the WinForm DLL. Both the C and the C# exe are also DPI-aware (as appropriate for their language) and both display correctly. Here's the logic flow. C or C# exe: - calls into the intermediate's cdecl entry point using the usual LoadLibrary / GetProcAddress mechanism intermediate mixed-mode DLL: - C entry point makes a call to an internal CLR function - CLR function marshals the parameters, does a gcnew on a C# class and calls its single member function - C# member function:

      Assembly targetAssembly = Assembly.Load (File.ReadAllBytes ("path to winform dll");
      Type startType = targetAssembly.GetType ("startupNameSpace.startupClass", true);
      object startLib = startType.InvokeMember ("", BindingFlags.CreateInstance, null, null, new object[0]);
      startType.InvokeMember ("startupMethod", BindingFlags.InvokeMethod, null, startLib, new object[] { marshalled parameters } );

      WinformDll: - startupNamespace.startupClass is NOT a form, just a plain C# class - startupMethod creates a parameterized thread, sets the apartment state to STA and starts the thread passing the marshalled parameters - the thread instantiates the first WinForm class with the parameters and calls ShowDialog So, here's the problem. When run from a C# exe, the DPI logic works correctly. I have a C#exename.exe.config file in the same directory with the exe that contains a "startup" section with my framework version number and a "System.Windows.Forms.ApplicationConfigurationSection" section containg the DpiAwareness key with a value of PerMonitorV2. When run from a C exe, the WinForm display is incorrect in the exact places where I have my DPI-handling logic. It's obvious from the display that the property DeviceDpi is incorrect for every form. The research I've done leads me to believe that the .NET environment created to run my winform assembly is missing the dpi awareness flag that is set in the config for the C# exe. I've tried adding a config file with all the different name permuations using the C exe name, the intermediate dll name, the Winform dll name, "exe" and "dll". Nothing is picked up by the NET subsys

      Richard Andrew x64R Offline
      Richard Andrew x64R Offline
      Richard Andrew x64
      wrote on last edited by
      #2

      .NET Framework or .NET Core?

      The difficult we do right away... ...the impossible takes slightly longer.

      J 1 Reply Last reply
      0
      • Richard Andrew x64R Richard Andrew x64

        .NET Framework or .NET Core?

        The difficult we do right away... ...the impossible takes slightly longer.

        J Offline
        J Offline
        JudyL_MD
        wrote on last edited by
        #3

        Framework 4.7.2

        Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups