0

I have a custom-built Windows desktop application that unexpectedly behaves differently on a system with multiple monitors, depending on how it has been launched. My expectation is that it should behave identically for each method of launching. Each method involves opening a file that has been associated to the application.

Here are the methods of launching I have tried and the resulting behavior:

  1. Double-click an associated file in File Explorer:

    Application launches, but the UI opens on whichever monitor File Explorer is on rather than on the primary display, as it has been written to do. Portions of the UI are also missing when trying to interact with the application.

  2. Drag and drop an associated file onto the application exe in File Explorer:

    Application opens on the correct display and behaves normally.

  3. Launch the application from a command prompt by running name_of_application.exe "file_to_open":

    Application opens on the correct display and behaves normally.

  4. Right-click associated file in File Explorer and choose "Open With...". Browse to the installed application and select it:

    Nothing at all appears to happen at first. Then after about 5 minutes, the application opens on the correct display and behaves normally. After that, opening the same associated file again results in the same behavior described in methods 1-3, once again depending on how the file is opened.

I'm not sure if it matters, but this is a .NET application written using the WPF framework that targets .NET 4.7.2. It is a 64-bit app. The code requests the primary monitor from .NET, which corresponds to the user's system display settings.

I have inspected the relevant registry entries for the file association and nothing seems out of the ordinary. See the following screenshots (associated file type is .sejs):

File type association in registry

Application association in registry

I also tried removing the "Command" value shown in the second image from the registry, which had no impact. As far as I can tell, there is nothing unusual this file association that would cause this behavior.

I have also tried rebuilding the installer, repairing the installation, and rebooting my machine.

This leads me to a couple questions:

  1. What would cause Windows to open the application on different monitors based on how the associated file is sent to the application?
  2. What would cause a long delay in Windows opening the application if I'm opening it during re-associating a file to it?
  • Please clarify in your post the various scenarios and their results, at the moment it's all mixed up. – harrymc Oct 26 '18 at 17:02
  • @harrymc Yeah, I guess that did get a bit messy. Sorry about that. I have rewritten the post, which hopefully makes things clearer. – HotN Oct 26 '18 at 20:13
0

The effect you describe would depend a lot on the system call that launches the file. The Windows API call for executing a program has many parameters, so it all depends on the Microsoft programmer in question.

Such differences are common in Windows, which has an enormous code-base written by many programmers. One has to learn the differences and adapt, since Windows is a closed system. You/we cannot "repair" Windows.

| improve this answer | |
  • Could you elaborate more on "it all depends on the Microsoft programmer in question"? I am the developer of the app that is being launched, but as far as the code can tell, double-clicking an associated file vs. dragging and dropping a file on the exe both result in the app launching with only one startup argument provided by Windows, which is the path to the file. As far as the app can tell, both methods of launching are identical. – HotN Oct 29 '18 at 16:12
  • It is normal in this case to have only that one parameter. My answer related to the choice of the monitor on which the display occurred. Regarding the 5 minutes delay, this is a problem of your app which only you can resolve. I have never encountered such problem, except when non-existent URLs or network shares were referenced. – harrymc Oct 29 '18 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.