JUCE 7.0.4, Windows 10, Windows 11 - code built using Visual Studio 2017
SDK 10.0.22000.0 - also tested with 10.0.16922.0 with the same result.
I have a dialog box with a number of label fields configured for user-driven text entry.
A number of users and I have observed a behaviour where, on opening the dialog box, clicking on a label fails to start the text edit process - the label remains inert.
The recovery is to close and re-open the dialog which - most of the time - resolves the issue. When this issue occurs - all of the editable labels in the dialog fail to respond.
In the juce_Label.cpp code - ::showEditor is being called and appears to run normally in response to the mouseUp event over the label - I can trace execution in normal and abnormal cases through to L244 in juce_Label.cpp - however the text editor and editor functionality does not start in the abnormal case.
This issue has only recently been reported and pre-dates my recent update from JUCE 7.0.3 to 7.0.4.
Has anyone else observed this issue? Any insights?
Additional observation - the same symptom is affecting combo boxes as well as text edit. The display is not reflecting any typing or control - however when I close the dialog the underlying data has been changed. It just appears that the editor (for label) is not appearing on the screen - and for the combo box the text on the collapse of the popup menu is not changed to the new selection in the box.
We’re seeing similar issues with edit and combo boxes after switching to 7.0.3. It seems to happen randomly, but the UI seems to freeze and there no visual updates on mouse-over, clicks, etc. It’s only the visual update that’s failing, so you can change the selected item, edit text, etc., but there’s no visual feedback at all. Hoping for a quick fix…
It’s probably important to mention that the issue only seems to occur when using modal loops (running runModalLoop() for the Component class). It looks as if the message loop doesn’t work properly. It’s a bit random – sometimes it works, sometimes it doesn’t for the same dialog box.
Thanks for your reply! It’s a stand-alone application built entirely with JUCE and it’s quite convenient to have those modal dialog boxes. I tried to make a minimal project to reproduce the issue, but there must be some other interactions going on there. A test component with a combo box, an edit box and a button that works well in the minimal project, fails when I add it to our application (copy and pasted the component code). I’ll try to find out more. The symptoms are exactly the same as in the original post, so I don’t think it’s specific to our app.
The dialogs that display the error condition in my case use the DialogWindow::showModalDialog method. I assume these back-end onto runModalLoop. I am rewriting the code using the DialogWindow::LaunchOptions mechanism and will report findings back.
It is frustrating to suddenly get this kind of weird error in code that has been running unchanged for - well, last edit on this file was 4 years ago…
I have spent the last few hours trying to isolate the change that has caused this issue. Findings so far:
I can write a simple application that fires up a dialog in the way my application does, and it does not exhibit the issue. The dialog seems to work just fine. So a simple code example may be a problem. There is some deeper interaction at play.
Recompiling my system against JUCE 7.0.0, 7.0.1, 7.0.2, 7.0.3 and 7.0.4 all display the issue. I skipped a few generations and I only started getting end-user reports last week after a couple of releases against 7.0.3 and the development test against 7.0.4. Previous versions were compiled against 6.1.6 and earlier.
THIS ISSUE DOES NOT APPEAR TO HAPPEN ON A WINDOWS 10 machine. I have only recorded the behaviour on Windows 11 where it is consistent (1 in 5 or worse launches of the dialog). I have asked a client to test against other windows 10 and 11 machines. I should get some results tomorrow.
Next steps are to:
a. See if this happens in 6.1.6
b. Dive into the debugger and see if I can trace the failure path.
Thanks for that. I regressed back to 6.1.6 and the issue presents at every version - but the frequency of it happening seems to be different in each case. Suggests to me that there is some underlying timing issue going on.
I am going to dive in deeper and see if I can trap what is causing the editor to not display. Watch this space.
I have not been able to extract simple code that demonstrates the issue. The mature application that is exhibiting the problem is a large piece of code.
I hope that this video may shed some light - captured to illustrate the problem in action. Note that I have rebuilt against 6.1.6 - 7.0.4. The issue is present in all cases it is just the frequency of the occurrence does appear to change. 1-in-3 to 1-in-5 is common, and occasionally it might take 3 or 4 attempts to get the dialog to work (open, cannot use it, close, re-open).
I modified my application logic to make use of the .launchAsync mechanism rather than the modal model. This appears to have solved my issue. The trouble is there are a few places in the code where I need to make the necessary logic changes so I am doing them piece by piece as issues are spotted.
I have spent some time debugging and have not observed what is occurring differently in the executions between a dialog that displays and operates normally and one that locks up.
For now I have a way forward - and am just marking the .runModal mechanism as ‘to be avoided’ and I will eliminate it from my codebase going forward. My guess is this is not going to get fixed. Prove me wrong JUCE team!
I’ve investigated this further, and I believe the issue is related to the deferred repaint logic in JUCE. Normally, the method HWNDComponentPeer::onVBlank will be called, which then again calls dispatchDeferredRepaints to perform the actual rectangle invalidation in Windows. However, onVBlank is never called when the errornous state occurs. If I add a call to dispatchDeferredRepaints in the repaint (const Rectangle& area) method, everything seems to work fine: