Different behaviour running with/without debugger or standalone (windows, VC++22, wx2.3.3.1)

[JerryTheC]

I'm changing an existing program (for Windows) from an ansi build with wxwidgets 2.8.12 (which works OK)
to a unicode build with 3.2.2.1.
For the unicode build I'm using visual studio 2022 c++ with wxWidgets 3.2.2.1.

The latest issue I've run into is that things appear to behave differently depending on whether I'm running the program from
Visual Studio 2022 (either with or without the debugger, via the filled or outline "play" icons), or if I run the program by copying
the executable and then clicking on it.

When run from Visual Studio, either with or without the debugger, things work as expected. When run standalone, It looks as
though the program is having layout/refresh/update problems. I suspect that it's getting stuck in a Layout related loop somehow -
when switching to a result display view (Earlier views appear to be working OK),
adding logging to some OnSize routines shows expected calls when run from Visual Studio,
but a loop with the OnSize routines getting called repeatedly when run standalone with some display twitching (and ignoring further
clicks).

I'm assuming that the repeated OnSize calls (with the same sizes) are probably related to some sort of layout or sizer loop -
but the client sizes appear to be stable, and the problem only appears to show up with the standalone version when the program
is in the foreground. Attaching with a debugger typically shows the program painting the display.

The different views are done by having a horizontal box sizer containing various panels - to switch between views, I show the
desired panels,and hide the unwanted ones.

Any ideas on what might be causing the loop (or why the problem only seems to show up when run standalone rather than via
Visual studio?). (Running with Windows 10, if that's relevant).

[[email protected]]

What happens if you don't copy the executable, but leave it where it is and just double click in explorer?

Did you use a debug build of both your application and the wx libraries?

Do you load any external resources (images, etc) that maybe are not found when running outside VS?

[JerryTheC]

The program loads data (settings files etc) and runs tool programs from subfolders using relative paths. With visual studio, these paths live under the source folder, with the build executables in different subfolders. That's why I've been copying the executable to the correct place so that the
relative paths work as expected. If I just run the executable from the build subfolder, it doesn't find the relative path files.

At the moment I've been using a release build of the application and libraries (but with info so I can step things through with the debugger).

As far as I know, there shouldn't be any missing external resources - they're either in relative paths or in known absolute drive-related paths,
and the program appears to be loading images and job data OK for both visual studio and standalone versions, and appears to be working OK
through the initial stages of loading images - the problem shows up when switching to a different set of panels when viewing results.

[doublemax]

At the moment I've been using a release build of the application and libraries (but with info so I can step things through with the debugger).

Please run a debug build. Maybe there are some asserts that you're not seeing.

What about the manifest? Does the GUI look the same both in working and non-working state? ( if there is no manifest, controls will have the old Windows 95 look)

[JerryTheC]

Made a debug build of wxWidgets and the program.

Ran into a couple of minor debug asserts - one formatting an invalid date time (in a last changed check, picking up the invalid default value when
adding a message to the log, fixed by adding a check), and one XML assert when freeing a doc (hadn't linked an element in).

Still showing similar problems when running standalone - works OK but appears to get stuck in a display update loop (for some reason, the close button on the top level frame briefly shows with a red background when updating, and when it starts looping it's flickering red continuously).

GUI appears the same both when runningunder visual studio and standalone.

[JerryTheC]

Manifests:
From the application:
intermediate application:

Code: Select all

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32'              name='Microsoft.Windows.Common-Controls'        version='6.0.0.0'                               processorArchitecture='*'                       publicKeyToken='6595b64144ccf1df'               language='*' />
    </dependentAssembly>
  </dependency>
</assembly>

application:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

from my wxwidgets:
wx.manifest:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    version="0.64.1.0"
    processorArchitecture="x86"
    name="Controls"
    type="win32"
/>
<description>wxWidgets application</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

wx_dpi_aware.manifest:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
      <!-- Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
    </application>
  </compatibility>
</assembly>

wx_dpi_aware_pmv2.manifest:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, system</dpiAwareness>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
      <!-- Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
    </application>
  </compatibility>
</assembly>

[doublemax]

Sorry, but I'm out of ideas here. If it's not the environment (paths, etc), i can only assume that the exe inherits some attributes from the calling IDE that cause the strange behavior. But i have no idea why, what or how. I'm using VS for many years and never had anything like this.