Handy setUsingNativeTitleBar(true) tips for YOU!

Windows
1

If you want to use a native Windows title bar there are some subtle behaviors that you need to be aware of if you want to get things to work perfectly. First of all there is an issue where sometimes when you launch your app, the TopLevelWindow it creates will not come to the front. This is especially noticable during debugging, when you launch your app the window appears behind the IDE!

The solution for this problem is not to let the TopLevelWindow add the window to the desktop (by passing true for addToDesktop in the constructor of TopLevelWindow, DocumentWindow, or ResizableWindow).

Instead, you will need to call addToDesktop() yourself, but there are certain function calls that MUST happen in a particular order or else you will not get correct behavior. The proper order of operations is:

  • Construct your TopLevelWindow with addToDesktop=false

  • Call setMenuBar() if you are using a menu bar

  • Call setResizable() if you want it to be resized

  • Call setConstrainer() if you want a constrainer

  • Now call setUsingNativeTitleBar (true);

  • Call addToDesktop (getDesktopWindowStyleFlags()); /* MUST happen after setUsingNativeTitleBar() !!! */

  • setContentComponent (contentComp, true, true); /* MUST happen after addToDesktop()!!! */

  • centreWithSize (getWidth(), getHeight());

  • setVisible (true);

The creation of a TopLevelWindow that uses a native title bar is sensitive to the order of how you call these functions in the constructor. If you don’t get them in order, you will have odd behaviors for example the window might not come to the front on launch or your content component might be a different size than what you set it to.

Rather than Jules wasting his precious time figuring out this windows-specific crap, you can fix it yourself by just following these guidelines.

Everything here applies ONLY to native title bars under Windows.

1 Like
2

Thanks. I think this is still happening, even for Mac. Please try to fix, thanks.

3

Try to fix what, exactly? AFAIK nothing is actually wrong, although like Vinnie says, if you’re not careful about the order in which you set things up, you can end up forcing the system to delete and re-create several native windows unnecessarily in quick succession, which will probably confuse the OS.

4

I have found in the past that getting a native window app to show up correctly (not behind other applications, with a non-null size, and without flickering or visible resizing) was pretty hard to get to work with the same code on all platforms at once (macos, win32 and linux)