I’m working on refactoring an old diagnostic tool to use a threading model. I thought that Control.Invalidate was used to just schedule that object’s refresh in the next Main loop sequence. However, I’ve just discovered that it causes a TAUI exception. Is this to be expected?
In my thread, I set property values that are used to update elements of a UI. As I assign the values, I call the proper object’s .invalidate function. When I run, as soon as I execute the first .Invalidate, I get the TAUI exception.
If the TAUI is valid, then the docs for .Invalidate need to be updated to note that it is NOT thread safe. If it not supposed to raise a TAUI when called from within a Thread, then I guess I have a bug report to file.
[quote=478975:@Tim Jones]I’m working on refactoring an old diagnostic tool to use a threading model. I thought that Control.Invalidate was used to just schedule that object’s refresh in the next Main loop sequence. However, I’ve just discovered that it causes a TAUI exception. Is this to be expected?
[/quote]
xojo2019 r3.1
i think the only way is to use AddUserInterfaceUpdate with or without dictionary.
and in the UserInterfaceUpdate you set the ui elements. UserInterfaceUpdate
hooking up a timer purely in the threads code has been discussed many times and its pretty simple to do
when the action event of the timer fires you are 100% on the main thread and can do whatever you’d like then
thats worked pretty much since the thread accessing ui exception was first added
What makes you think so? It is a Thread accessing GUI Exception, and your thread must access the GUI element, otherwise it could not invalidate it.
I do admit that the explanations given in the documentation telling the OS to mark the control as dirty can lead to the impression that an Invalidate talks to the screen manager somehow and not to the GUI directly. This might be the case technically, but it is still done via a method of the control itself.
Unfortunately, that’s is also causing the TAUI exception under 19r1.1.
[quote=478986:@Norman Palardy]hooking up a timer purely in the threads code has been discussed many times and its pretty simple to do
when the action event of the timer fires you are 100% on the main thread and can do whatever you’d like then
thats worked pretty much since the thread accessing ui exception was first added[/quote]
The issue that I ran into here is that the Dialog didn’t always appear when the timer fired on Linux (just like the Xojo launch splash screen) and I was trying to work around that issue.
@Christian Schmitz - That was after I’d relocated the RefreshThreadSafeMBS call to the thread from the Timer’s Action callback.
Again, the problem that I’m trying to work around is getting these dialogs to show up 100% of the time on Linux without using App.DoEvents as I did back under RS 2007r3.
@Christian Schmitz - I fixed that by placing a Me.Sleep(100) between the Timer mode call and the refresh call. So:
The timer works as it should setting up the dialog for display
Placing the dialog’s .RefreshThreadSafeMBS in the Timer’s Callback after the .Show call doesn’t get it done on Linux
My display solution is to move the dialog’s RefreshThreadSafeMBS call in the thread code, but place a Me.Sleep(100) call in the thread between the timer launch and the RefreshThreadSafeMBS call
