@Christian-Ehrlicher
Thank you, it helped!
In fact, these two commits contained what I needed:
Fix dragging a docked QDockWidget [REG-fix]
430985: Refix QDockwidget drag out dockwidget

@SGaist,
Qt 6.3.2, Windows 10.

I found that winapi coordinates I got eventually turned out to be different from QCursor::pos() when talking about switching between different scales. So I decided to use QCursor::pos() instead, and it helped:

QPoint globalCursorPos = QCursor::pos(); auto menuGeom = ui.qMenuBarMain->geometry().translated(ui.qMenuBarMain->mapToGlobal(QPoint(0, 0))); if (menuGeom.contains(globalCursorPos)) //some work

@SGaist

Hello,
my bad. I'm using Qt 6.3.2 on windows 10 and msvc.

It is indeed a bug, see: https://bugreports.qt.io/browse/QTBUG-106707

I finally found a solution which seems to work in my case. I added the Qt.MSWindowsFixedSizeDialogHint window flag, which seems to fix the issue.

So below is the modified code:

ApplicationWindow { // common properties id: awMainForm width: 602 height: 728 flags: Qt.Window | Qt.FramelessWindowHint | Qt.MSWindowsFixedSizeDialogHint visible: true // form content isn't relevant ... }

@texasRanger said in Multiple UI windows??:

Solved here:
https://forum.qt.io/topic/99477/multiwindow-in-qml-proof-of-concept/7

The solution in this post is unnecessarily complicated.

In your question about them being blank I don't understand what you are doing

//main.qml QtObject { property Window window1: Window { visible: true // ... } } //FirstForm window1 { //UI formating }

How are those two related?

Why not do this?

//main.qml QtObject { property Window window1: Window { visible: true // ... FirstForm { anchors.fill: parent } } }

@Calvin-Richerd

On OS I'm familiar with, the OS's notion of "fullscreen" means "full screen" and not "full desktop". However you can fudge a multi-window full-desktop window by digging into desktop geometry via http://doc.qt.io/qt-5/qdesktopwidget.html and creating a sufficiently large borderless window. Not sure how things work these days but it used to be that even if the screens had their own GPUs, all of an application's rendering would be done by one screen's GPU, and then that would be copied to the other screens. If performance is important it maybe better to create a multi-window application with a window on each screen.

Couple of ways of doing this:
a. Render the window to some offscreen framebuffer, then do 2 copies of the rectangles on either side of the wrap line to the appropriate parts of the actual screen. ie if your framebuffer contains [ABCDEF] but it's rotated 2 characters then you'd copy [CDEF] to the left of the screen and [AB] to the right to get [CDEFAB].
b. Create an application which actually has content [ABCDEFABCDEF] and then just display the right subregion so it looks like its wrapped if you display [CDEFAB]. If the user goes off one end or the other just completely jump to the other end.

Not sure how applicable these ideas are to QML apps though. You can do quite a bit of messing with rendering using ShaderEffect, but that doesn't help route mouse events to the right place in a displaced "underlying" layout.

Thanks it works ! (but I put the setGeometry after the showFullScreen)

Ok I'll try

Thanks again.

Great that you found the flag. Since version 5.5 Qt on Windows does that dynamic choosing of the OpenGL driver. Since you always want the desktop version you can also build Qt yourself with a configure option -opengl desktop. This would disable ANGLE support entirely so that you wouldn't need the flag and also shrink the library a bit and reduce the number of dependencies for deployment.

I know this problem. ;)
I have never found an index in a book stating "the solution to your problem is on page xx".
Add a tag to multi-screen. There is also another post to a bug, but probably unrelated.

@Chris-Kawa Your post just what I am meet with. Thank you.