Hi everyone, and happy new year!
We finally move to Juce 8 for our next software release but I have two regressions on my no-title-resizable main Window:
OS taskbar button click does not toggle minimize state anymore
Maximise Window overlap the OS taskbar.
I also have a feature request:
I would like to have my no title resizable window bounds and placement to react with [window] + [directionnal arrow] keyboard keys.
For this 3 points, I modify the juce/modules/juce_gui_basics/native/juce_Windowing_windows.cpp line 2406 of function createWindowOnMessageThread() like this:
// [...] line 2046
if (titled || usesDropShadow)
{
type |= usesDropShadow ? WS_CAPTION : 0;
type |= titled ? (WS_OVERLAPPED | WS_CAPTION) : WS_POPUP;
// SMODE move some code outside the if bellow
}
else
{
// Transparent windows need WS_POPUP and not WS_OVERLAPPED | WS_CAPTION, otherwise
// the top corners of the window will get rounded unconditionally.
// Unfortunately, this disables nice mouse handling for the caption area.
type |= WS_POPUP;
}
// SMODE moved outside if / else section to let non-os based title bar based windows without drop to work on the following cases:
type |= hasClose ? (WS_SYSMENU | WS_CAPTION) : 0;
type |= hasMin ? (WS_MINIMIZEBOX | WS_CAPTION | WS_SYSMENU) : 0; // let toolbar app click toggle minimize state
type |= hasMax ? (WS_MAXIMIZEBOX | WS_CAPTION | WS_SYSMENU) : 0; // let Maximise does not overlap toolbar
type |= resizable ? WS_THICKFRAME : 0; // let windows became resizable with mouse and window key + directionnal keys
// end SMODE
// [...]
Doing this introduce a new mouse cursor hotspot offset bug when my no titlebar window is in fullscreen, but it can be solved modifying the getPointFromLocalLParam of the same file like this:
Point<float> getPointFromLocalLParam (LPARAM lParam) noexcept
{
if (!hasTitleBar() && isFullScreen()) // SMODE, cf case WM_NCCALCSIZE: tricks
return getLocalPointFromScreenLParam(lParam);
// [...]
// else fallback to the old code
Can you considere to add this fix in your code base?
It’s been a long time since I last visited the forum. Do you prefer Pull Requests now?
Thanks in advance for your concern about this
JUCE 8 changed the way that non-native titlebars work on Windows. If you look at one of the JUCE examples with a non-native titlebar, or build a blank GUI app with setUsingNativeTitlebar (false), you should see that:
the minimise button on the titlebar works, as does clicking in the taskbar to show/hide the window
win+arrow keyboard chord moves the window
maximising the window does not hide the taskbar
Therefore, I believe the behaviour you’re requesting is possible without modifying JUCE itself. To get this to work, make sure your window has the semi-transparent and temporary flags disabled and the drop-shadow flag enabled.
Hi @reuk
And many thanks for your reactivity concerning this subject.
Note that your solution clearly fix the 3 points without modifying Juce code.
By the way, I cannot let drop-shadow flag enabled.
This is because an historic issue that I need to sort out (may be related to Win32 or Juce, I do not realy know)
Sadly, drop shadow are still paint on maximized windows and I think this is a bad behavior (drop shadow should be paint only when resizable windows is not in maximized state)
As you can see in dual screen configuration, my Juce application maximized in Screen 1, leak shadow on my Firefox maximized on Screen 2:
(grey pixel on white region can be observed)
When I have a full screen GPU accelerated window at the right on my Juce maximized application on the left, the shadow paiting break gpu driver optimization and introduce performaces drop.
I do not know if you think something can be done for this case in a more cleaner way than my juce huge modifications?
Thanks in advance for your help about this.
All the best
I’m not able to reproduce this behaviour on Windows 10 or Windows 11. I’m testing with a blank GUI App with the native titlebar disabled. Please answer the following questions to help determine the cause of the issue:
How are you setting the maximised state? A default GUI app calls setFullScreen (true) on the component peer, which I’d expect to work. Are you using a kiosk component or some other technique to enter maximised state?
Please could you confirm that you’re running the latest version of JUCE develop with no custom modifications?
If so, do you see the same results with a new blank GUI App project (not your existing app)?
Do you see the same results with non-JUCE apps? e.g. if you maximise notepad on one display and a browser on the other?
Which Windows version have you tested? Do you have access to other Windows machines, and if so, do those machines display the same issue?
What scale factor are you using on each display? Do you get different results with different scale factors?
I clearly use setFullScreen (true) call to goes fullscreen without using any kind of other kiosk technics.
I do not reproduce the multli screen drop shadow issue with last version of Juce develop branch nor with other app but,
I succesfully reproduce the mouse hotspot offset bug when maximised by modifiying the line 38 of your last version of the file examples\GUI\WindowsDemo_artefacts\JuceLibraryCode\Main.cpp
By switching setUsingNativeTitleBar (false); // previously true
My last getPointFromLocalLParam patch should helps.
My windows version is Windows 11 Pro 24H2
Sorry for the late reply: I do not have time do perfom deeper testing.
My collegue reproduce the issue on its Windows 10 Pro 22h2.
My other collegue reproduce the issue on its Windows 11 Pro 23h2.
We are all using 100% scale factor on dual HD screen setup configuration.