Yeah, you found the problem alright The MsgBox isn’t even being displayed behind the window however it makes the sound and puts the window into a modal state.
Even if the columns are empty, changing ColumnAlignment causes a repaint, comment out both of those lines to be on the safe side and perform those actions outside the Paint, like in the Open or just before you load data. If you want to see it stuck in there, leave the lines in and add system.DebugLog(“PAINT”) after the lines and watch the debug output, it’ll never end, then try it with the two lines commented out.
You shouldn’t do anything in a paint that could cause the control to re-paint or you can end up in a really tight loop that effects the performance of the app in strange ways or even locks it up totally.
Glad you found it.
Thanks Julian - you are a champion!
Although I found which bit of code was causing the issue( took me half a day, and half a sleepless night), I didn’t understand why.
Thanks for the explanation!
Does the same issue still happen if you turn implicit instance off? Windows don’t inadvertently get dragged to the front with it off. I don’t have my work setup going on a Sunday so I can’t test on Windows, but if someone wants to explore that curiosity I’d be interested in the results.
I just turned it off an tried it, the problem was still there. Its probably more to do with the message queue jamming up due to infinite paint messages than anything else.
And everyone is wondering why Windows Graphics or Xojo-built Windows apps are so slow…
Me.ColumnAlignment(2) = Listbox.AlignLeft is already like that, a second
Me.ColumnAlignment(2) = Listbox.AlignLeft should not force a re-paint. Xojo’s Windows Framework could prevent that.
Such as it could prevent a whole lot of other unnecessary paint events being triggered. I guess that’s why I find a lot of (legacy) code like this in our project:
if (theControl.Enabled <> boolEnabled) then theControl.Enabled = boolEnabled. Even “worse” in situations where Controls are being re-positioned, because changing both .Top and .Left may cause a whole lot in the Windows being redrawn not just once, but twice… okay, that’s an uneducated rant, which should be double-checked with Xojo 2018/Windows. But it certainly caused a lot of flicker before that could be avoided like that.
Anyway - it seems that Xojo’s Windows Framework is nowadays even less tolerant of things like that… and I don’t know if that’s good or bad There are about 3 different Forum threads in within just a couple of days with weird bug descriptions - all caused by setting some “GUI property” in a .Paint-event.
I suggested earlier to try MessageDialog.
Today I have downloaded your example project and replaced the concerning MsgBox with MessageDialog.
'MsgBox "Worksheet is loaded and ready to use." + EndOfLine + EndOfLine + "Business: " + CurrentBASName + EndOfLine + "Tax Year: " + Str(CurrentBASYear) // Disable MsgBox and replace it with MessageDialog
Dim d As New MessageDialog // declare the MessageDialog object
Dim b As MessageDialogButton // for handling the result
d.ActionButton.Caption = "OK"
d.Message = "Worksheet is loaded and ready to use." + EndOfLine + EndOfLine + "Business: " + CurrentBASName + EndOfLine + "Tax Year: " + Str(CurrentBASYear)
b = d.ShowModal // display the dialog
When I run your your project and create a worksheet the message is shown as should be.
Windows 10 and Xojo 2018r1.1