Testing my app under Win7/10 today reveals that none of my threads is able to update the user interface via the Thread.AddUserInterfaceUpdate mechanism. The same code works just fine under macOS and Linux. I’ve tried this with both 2021r3.1 and the new 2022r1: same result. I’ve been testing both a built Windows app and remotely from macOS Mojave.
This could be because I’m not using the mechansim quite correctly so I’m open to suggestions. I’m not sure when this problem started.
What I have is a subclass of thread. To this I’ve added an event definition, a Constructor and a couple of other methods, and a number of properties which allow me to manage the threads as the app runs. One of the methods is named UIupdate and is as follows:
// UIupdate: Stores the requested UI update and sends it off for actioning.
Var UIdict As new Dictionary
UIdict.Value("action") = action
UIdict.Value("arg1") = arg1
UIdict.Value("arg2") = arg2
UIdict.Value("arg3") = arg3
UIdict.Value("arg4") = arg4
me.AddUserInterfaceUpdate (UIdict)
Most of my threads are subclasses of this subclass, and so they all use their super’s UIupdate, above.
Checking through in remote debug mode shows that this method is called and runs as expected.Now, what happens under WIndows is that this does NOT result in the Thread.UserInterfaceUpdate event firing, at all. I’m not even sure how to debug this. I can tell that the app runs as expected under Windows except that the UI doesn’t change unless changes are made via button action handlers and similar.
Edit: well an earlier version of my app runs correctly under 2021r2.1, before I converted to API2. But that was probably before I added the extra thread subclassing too, so some more testing is needed. Even so, what I have ought to work.
Thanks - yes that works under W10. Tomorrow I’ll morph it to look more like my app (move the Run method to the subclass etc) and see if I can make it fail.
After trying @MarkusR 's example, I changed it to reflect that portion of my app which (amongst others), was apparently not working. This worked OK under macOS and Windows. I did discover a couple of minor errors, so the exercise has been useful, but fixing these changed nothing.
Then under Windows I tried a couple more things in the app. In particular I had noticed that minimising the app and bringing it back again caused some messages to appear having apparently been queued up in the UI update system. So I tried another small window my app has for some housekeeping. It has athread which looks through some databases and normally generates a lot of output into a TextArea in the small window, as soon as I press its Start button. This time - nothing. BUT: as soon as I minimised the main window again - off it went at full speed. Bring the main window out of the taskbar (and then it takes 10 seconds to repaint itself), and it stops my small window DEAD.
It seems to be using some amount of CPU, but that could just be the overhead of VirtualBox.
So something in my main window is preventing itself and other windows from firing the Thread.UserInterfaceUpdate event.
Earlier this year I made a tweak to the headers in a DesktopListbox. As a result, essentially I needed to have the headers repainted, so when I’ve painted the last header I do this:
me.HasHeader = False
me.HasHeader = True
I’m doing this in the header paint content event. At the time, I was worried that this might cause an event loop, but under macOS/Linux this appears not to be the case. Under Windows, seems it is the case, and as soon as I commented these lines out, the issue described above went away. I guess what happens under Windows is that the event scheduling system gets overwhelmed. Interestingly, doing some profiling under Windows and macOS gives very different numbers for the numbers of calls to the header paint events.