[Bug]: JUCS Titlebar close button non-functional in Windows

[Kirsten-Hobby]

Detailed steps on how to reproduce the bug

I am using JUCE titlebar for main app (document window) & for modal dialog windows. The close button does not function so there is no way to close the main app window. If I change a modal dialog to Native (Windows) then that close button works. Bug exists in both 8.0.3 & develop branches

What is the expected behaviour?

Close button should close window

Operating systems

Windows

What versions of the operating systems?

Windows 10 Pro 22H2

Architectures

64-bit

Stacktrace

No response

Plug-in formats (if applicable)

VST3, Standalone

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[reuk]

I'm currently unable to reproduce this behaviour in testing.

Please can you provide some more detail about the exact steps you're taking in order to trigger the issue? Ideally, share a minimal code example that demonstrates the problem, or explain how to trigger the issue in one of the JUCE examples from the main repository.

In particular, it's not clear which close button is not working - the modal dialog's close button, or the main window's button.

I tried modifying a standalone plugin project to use a non-native titlebar for the Audio/MIDI settings window by changing line 313 of juce_StandaloneFilterWindow.h like so:

        o.useNativeTitleBar             = false;

The behaviour I see is as follows:

• When I first run the standalone plugin, the close button works as expected.
• When I run the app, then click "options -> Audio/MIDI Settings..." to open the modal settings window, then:
  • All controls in the main window, including the close button, are disabled because a modal window has focus, and
  • The close button for the modal window still works as expected.
• After closing the modal window, the close button on the main window functions normally again.

This is the behaviour I'd expect to see. Are you seeing different behaviour to this? If so, it would be helpful to test exactly the code you're running, in order to debug the issue. If you'd prefer not to share the code publicly, you can also reach us at info [at] juce [dot] com.

[Kirsten-Hobby]

Hi, Both minimise and close buttons are inoperative in both Document windows and Modal dialog boxes. Closing the window via Alt & F4 or pressing the escape button for modal windows correctly triggers the events that lead to the Window(s) being closed. I have tracked the issue to the message that is being generated when a window button is clicked. I added some debug code to dispatchNextMessage in juce_Messaging_windows.cpp in both versions of JUCE I have running. JUCE 7.0.12 Mouse down = 513 MouseUp = 514 These messages above correspond with the hex codes for WM_LBUTTONDOWN and WM_RBUTTONDOWN. JUCE 8.0.3 Mouse down = 161 MouseUp = 162 These messages from build 8.0.3 do not result in the relevant events being raised and their generation appears to be responsible for the lack of button functionality for my project. I know this does not help you reproduce the issue but I thought it might help a little. I tried a couple of demo projects and they work normally so the only other thing I could do is to try create an emulation using the same custom StandaloneFilterWindow class I am using in my project. Thanks in advance Kirsten

[reuk]

If your window is fully custom, and doesn't inherit from DocumentWindow, perhaps you need to override Component::findControlAtPoint. The implementation for DocumentWindow is probably a good starting point for a custom implementation.

[Kirsten-Hobby]

Hi, Done some more investigative work and built a new plugin in V8.03 to compare against my project that works fully in V7.0.12. When the GetMessage macro is called in dispatchNextMessage (juce_Messaging_windows.cpp) the wParam value is incorrect when I run my project in V8.0.3. My project Test Project created in V8.0.3 I pressed the minimise window button and wParam = 8 is the correct value. I can track this further through the code to successful implementation. The wParam value of 2 generated by my project is passed through the same code but hits a switch (in peerWindowProc ) where there is no matching case so nothing happens. Both times the code is referencing the same file (WinUser.h) in the same non-JUCE related location Cheers Kirsten

[reuk]

Please try implementing Component::findControlAtPoint and/or deriving your custom window from DocumentWindow as I suggested above, and check whether that helps.

[Kirsten-Hobby]

Hi, Sorry I was unclear. I am using my own version of standaloneFilterWindow class which inherits from DocumentWindow. Window looks like this. The white border appeared in V8. When I hover over the minimise or close buttons they are painted differently so the mouse hover is being detected. Ran through code in peerWindowProc and the buttons are not identified @ const auto kind = component.findControlAtPoint (localPoint); Cheers Kirsten

[reuk]

How are you adding your buttons to the document window?

The DocumentWindow implementation of findControlAtPoint does the following:

for (const auto& [control, kind] : { std::tuple (getMinimiseButton(), WindowControlKind::minimise),
                                     std::tuple (getMaximiseButton(), WindowControlKind::maximise),
                                     std::tuple (getCloseButton(),    WindowControlKind::close) })
{
    if (control != nullptr && control->contains (control->getLocalPoint (this, pt)))
        return kind;
}

So, if you're adding additional buttons instead of styling the buttons that the window creates, this implementation won't work for you. You'd need to override the function yourself to do the right thing, or change your window implementation to use the buttons provided by the DocumentWindow. I recommend actually debugging into DocumentWindow::findControlAtPoint to find out why it's returning client.

[Kirsten-Hobby]

Hi, My Document window does not have custom buttons. Went through code findControlAtPoint and deduced my issue is cause by using Desktop::getInstance().setGlobalScaleFactor(). My main window is fixed aspect ratio but I have a scale setting which resizes the main window. I am using Desktop::getInstance().setGlobalScaleFactor() to change the font sizes when the magnification factor is not 1.0. So it seems that the value set Desktop::getInstance().setGlobalScaleFactor() is also scaling the point values returned from findControlAtPoint, so it returns incorrect scaled point values when setGlobalScaleFactor is not 1.0. Thus it does not return the buttons as the source because most significantly the pointX value is incorrect. Hopefully you can now reproduce this and fix it 😊 Cheers Kirsten