“Save Project” and “Save Project as…” open modular windows in Windows 10.
On a primary monitor they work great.
However, if Pro Motion NG is on a secondary monitor (in my case, Wacom 24 Pro), the window pops up somewhere where you can’t see on the screen. As a result, the program soft-locks, pinging whenever you try to click on anything.
Workarounds:
Make your working monitor primary.
When the program soft-locks, Alt-F4 to kill the invisible modular window, then drag your program to the primary monitor and save there.
This problem happens whether you use File menu or the shortcut (Ctrl-S).
Can’t duplicate, but on my system the “Save as…” dialog pops up on the primary monitor, which is also not desired. Seems to be a problem in the UI system I use. So far I did not find a workaround.
Somehow, it got even worse on my machine, now I can’t “Save as…” on primary or secondary monitor. Please fix as soon as possible, this is now an absolute blocker bug.
Windows 10. Two monitors. Can’t see “Save as…” dialog for anything. It’s nowhere to be seen.
The desired behavior for it is to pop up in the center of the monitor where the window is. Or the center of the window, perhaps, if it is stretched over several monitors?
Please let me know if you know of a workaround. I love your software and I want to use it, but I can’t.
Okay I have figured it… or at least enough of a workaround to resume working.
I have two monitors. Although they are physically similar in size, resolution on my newer monitor is nearly three times as high. I usually keep this new monitor off, and it is not my primary monitor. Half the time, I have the newer monitor in a vertical position.
However, I need to make it my primary monitor when I work in Pro Motion NG because the modal windows keep popping up where I can’t reach them with the stylus.
If I keep moving my program window between the two monitors (say I needed to save/export a file really quick without any serious alterations), I may end up in a situation where the modal window pops up on the primary (low resolution) monitor with the offset from the secondary monitor (high resolution) so I cannot see the window, and I cannot access it even from Shift-right click -> Move with arrow keys panel, because of reasons you’d be more familiar with than I. This can lead to a severely broken state.
I was able to get out of it by dragging window back and forth and rearranging windows and swapping monitors until I got the modal window to display on the big screen. But, you know, a couple panic attacks later as my frantic posts have illustrated.
I think the whole bucket of pain would be avoided if the modal windows always popped up on the same screen as the program, regardless of which monitor is the primary.
I’ve also noticed that the certain container windows (brush container, view, tool and paint settings) resize themselves according to the resolution of the primary monitor, not the monitor the program is on currently, even if you try ‘Options -> Windows -> Rearrange windows’ to bring them back in line.
I’ve also noticed that the certain container windows (brush container, view, tool and paint settings) resize themselves according to the resolution of the primary monitor, not the monitor the program is on currently, even if you try ‘Options -> Windows -> Rearrange windows’ to bring them back in line.
Can you explain this with a screenshot? These windows use the size and position of the main window when using the arrange function, so I can’t see a connection to the monitor size. I checked with different monitor resolutions (1st monitor = Full HD, second 1366px).
Will try to force the load/save dialogs to open where the application main window is, but no luck so far. This is handled by the UI sysem/windows and I need to find a way to alter their default behavior.
The positioning of the load/save dialogs is only correct if I use those that are built into Windows since Vista. At the moment I still support XP and I also need to check if those dialogs are available with Wine that is used for Mac and Linux compatibility.
The positioning of the load/save dialogs is only correct if I use those that are built into Windows since Vista. At the moment I still support XP
I remember that trying to work with 2 monitors on XP was a real nightmare (even with SP3)! I actually had to purchase a third party app in order to be able to have some key shortcuts for moving windows from one monitor to the other. Trying to use one monitor vertically would add more problems. With Vista support for dual monitors started to be more decent.
Chances are that in order to allow proper functionality for dual monitors (and other modern Windows features) you’ll have to drop XP compatiblity — which, if I’m not wrong, will also happen when DPI awareness support will be introduced. At least, in some languages IDE’s I work with, I have to enable modern Window support in order to be able to access functionality for handling multi-monitors and DPI awareness, and I believe that this might be a limitation tied to the WinAPI.
In the long term, trying to preserve XP backward compatiblity is going to be painful and limiting (IMO). As for Wine, that’s another thing. Possibly, you could create two releases of PM, one with XP compatibility features, the other with modern Windows feature enabled. I had to do that with some apps I wanted to release for both XP and modern WIndow, by using compiler directives to handle both settings.
XP compatibility is nothing I will try to keep under all circumstances. I just wanted to say that it’s still there. I will drop it if it is required, but I need to have a look at the Wine compatibility. That’s more important. Will try to check this soon. Also it should not be too hard to support both types of the file I/O dialogs within a single version.
