Results 1 to 4 of 4

Thread: QMainWindow movable while maximized?

  1. #1
    Join Date
    Mar 2006
    Posts
    26
    Thanks
    2
    Thanked 1 Time in 1 Post
    Qt products
    Qt3 Qt4
    Platforms
    Windows

    Default QMainWindow movable while maximized?

    Qt 4.2.2, Windows XP (Home)

    The following code produces a maximized window that can be moved by the user:
    Qt Code:
    1. xyzzy.setWindowFlags(xyzzy.windowFlags() & ~(Qt::WindowMinimizeButtonHint | Qt::WindowMaximizeButtonHint));
    2. xyzzy.showMaximized();
    To copy to clipboard, switch view to plain text mode 
    If I remove the Qt::WindowMaximizeButtonHint from the above code, I get a maximized window that cannot be moved. I do not know the size of the desktop, nor if the task bar is displayed. I need the main window to take up all desktop space and not to be able to be moved around.

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QMainWindow movable while maximized?

    How about using QWidget::showFullScreen() ?

  3. #3
    Join Date
    Mar 2006
    Posts
    26
    Thanks
    2
    Thanked 1 Time in 1 Post
    Qt products
    Qt3 Qt4
    Platforms
    Windows

    Default Re: QMainWindow movable while maximized?

    I still would like to have the title bar and the close button, and showFullScreen() gets rid of these.

  4. #4
    Join Date
    Aug 2006
    Posts
    44
    Thanked 7 Times in 7 Posts
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QMainWindow movable while maximized?

    I'm betting you're working in MSWindows.

    Windows does this automatically. The underlying OS window style doesn't include a 'maximizeable' style, so certain behaviors are removed from the window. However, the underlying API doesn't prevent you from executing the 'maximize' operation. Since the window doesn't have a restore button on it (since it has no maximize button), I'm betting they decided that such a behavior was a Bad Thing -- so users can move the window.

    You can work around this by injecting some Windows-specific code. (I've fixed exactly this bug in a commercial product... so I'm not sure if my employer will appreciate me giving the fix away. :P)

    You'll need to modify how your window handles the WM_NCHITTEST message. To be complete, you should also try to customze the system menu for the window and the handing of WM_SYSCOMMAND events, since the user can still move the window via those options. There may be other holes, as well.

    I haven't (yet) investigated if there are similar problems on X / Mac (my product also ships there, but only to a tiny fraction of our users compared to Windows).

    Hope this helps.

  5. The following user says thank you to Eldritch for this useful post:

    Byngl (12th November 2007)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.