I have a canvas array on a modal dlog window. I’m pretty sure before this worked, but now the canvases don’t refresh (and don’t receive paint events) when other operations in the dlog window call self.Refresh (where self is confirmed to be the parent dlog window). I have to explicitly loop thru each canvas in the array and call myCanvas(j).refresh to get them to update. This can’t be right.
v2021r3.1 on MacOS Mojave.
I reported something like this a while back (don’t have the Feedback # handy). It’s apparently a change at the OS level Apple made (or so I was told). The only workaround that I’m aware of is what you’ve done.
1 Like
Thx Bob, it does coincide with my “upgrade” from HS to Mojave, so probably macOS not Xojo.
I’m pretty sure it was Mojave when we started noticing this.
I wrote a function for the Ohanaware App Kit that when called invalidates the window, then steps through every control on the window and if it is rectControl calls invalidate on that too. I used declares so I could check each control for children and update them also.
This way is kinda useful so I can call invalidate on the window and it will ONLY update the layer for the window background and not all the controls.
This is worse than I thought: i have listboxes where i add/delete rows in code, simple stuff, AND I call listbox.refresh every time, and still the rows do not appear unless i click in another control (of course you cannot trace this anomaly in the debugger because the context switch forces a refresh, only in the built app w/o debugger).
I have to call app.DoEvents after calling refresh to actually get the box to update. To have these simplest of things not work and then to waste time working around is really awful. Don’t know if this is xojo’s or mojave’s fault. Either way it’s a PITA.
1 Like
When you call refresh, are you adding the “True” argument so the refresh updates immediately?
window.refresh(True) ← will update all controls immediately
**This has been the fix on Windows using the updated Xojo API 2.0 for a similar case of multiple canvases not refreshing.
***Desktop apps should never see the command “App.DoEvents” - somewhere down the road, your app is most likely to have undesired results occur. Try Thread.SleepCurrent() if you absolutely need to (really should not be needed).
My refresh call is with no arguments so TRUE is the default according to the LR. I just now tried FALSE for the newly-discovered listbox issue and it did not work either. So the conclusion “will update all controls immediately” is simply not true on Mojave (it was true with high Sierra).
Yes, we’ve all seen these warnings for years. I’m sorry to say that there are some instances where DoEvents is essential. Much to my annoyance, the current “force the listbox to refresh” case is one, and also (off-topic) another important one that I’ve discovered: when you are running a long operation in a thread and want to update the UI from the thread using the Thread.UserInterfaceUpdate mechanism, and the main thread is synchronously waiting for the operation to complete using SleepCurrent calls as you suggest, the UI will not be updated. The main thread must wait with periodic DoEvents calls instead for the UI to respond to the subthread’s UserInterfaceUpdate events. I found no way around this, so DoEvents can never be completely dispensed with as far as i can see.
Can you share any code? This is very odd behavior for a listbox.
Is it a Window or a DesktopWindow? For Window, the argument is EraseBackground and the default is TRUE. For DesktopWindow, the argument is Immediately, and the default is FALSE.
1 Like
Window