12 ms·
No it's all Qt. I've tried fixing a few cases but yeah, seems something fundamental to the Qt library. I'd like to think that dialog will probably go away and
by wizofaus 3y ago
No it's all Qt. I've tried fixing a few cases but yeah, seems something fundamental to the Qt library.
I'd like to think that dialog will probably go away and be rolled into the properties pane, which I gather is Martin's (tantacrul's) preference.
- kazinator 3y agoOK, so I now know of three instances in different software of a similar issue on Windows: a window coming up in the background. One is in Qt (as manifested by this MuseScore behavior with the dialog). The other is a long-standing thing in GTK+, visible for instance in the Windows version of GIMP. Then there is this funny issue I fixed in something called the Cygnal project (a fork of the Cygwin DLL): https://www.kylheku.com/cgit/cygnal/commit/?id=5d50aea73aace09f914ff95d90b771270aef1ab8 https://www.kylheku.com/cgit/cygnal/commit/?id=5d50aea73aace... When a program that has never serviced its Windows message pump runs another program via CreateProcess, and that program creates a window, that program's window fails to come to the foreground. This goes away with a dummy call to TranslateMessage. I have a vague feeling this could all be related.
- wizofaus 3y agoI just assumed it was because the window owner wasn't set properly (but it's a long time since I did windows desktop app development). Strangely I can't reproduce the problem now - you can certainly send the dialog behind the parent, but it comes up above it initially as expected.