HI Folks,
I’ve been asked to bring forward an old tool set (RB 5.5 era) to modern OS X and Linux. There are a plethora of instances where I did naughty things from within threads back then.
Is there a way to locate these instances short of running the project over and over to catch each TAUIE? I’ve tried to add an Unhanded Exception handler at the app level, but that doesn’t seem to allow things to continue even though I return True in the even if a TAUIE.
I doubt very much you can get away with UnhandledException. It probably messes up with the thread run itself.
The only soft way would be to read the code line per line for mentions of UI controls, and then use a task or a timer.
You can walk yourself over the code and look for references to controls and Windows.
E.g. If that in a thread class, you can search inside for control or window.
Thanks, guys. What I’m trying to overcome is the fact that I tend to write callbacks for common items and then call them form the threads as well as the main loop code. This results in instances where the code may never be called within a thread, or it may be called multiple times in a thread loop.
It’s a real PITA to have to examine any assignment in such a large app to refactor any control.text = string or the like to set a variable and then kick off a timer.
Have a look at http://www.realsoftwareblog.com/2012/10/detecting-ui-access-from-threads.html. Haven’t used it myself, but may help.
Thanks, Wayne.
That looks like it will end up doing the same thing as run - TAUIE - edit - run - next_TAUIE - edit - run … that I’m doing now. The difference being that the IDE at least takes me to the location in my code :).
Sub class the threads (which will help to make them UI/Thread safe).
Hi Sam,
Thanks, but since I already sub-class threads for my purposes, I’m not sure what I’ve missed there. What else might I be missing?
[quote=306635:@Tim Jones]Hi Sam,
Thanks, but since I already sub-class threads for my purposes, I’m not sure what I’ve missed there. What else might I be missing?[/quote]
we all would love to know.
depending on how complex your UI update from the thread was you might be able to get away with just adding a property to the thread that is a timer that gets set created and has its action handled via add handler to a private method added to the thread
move the ui update code in there and have the timer be started as part of starting to run the thread and set some period for it to do ui updates
since its part of the thread any properties of the thread are accessible to it
and the ui updates are always done on the main thread
The easiest way to deal with the exception that I love the mostest is to use
CallDelegateOnMainThreadMBS AddressOf "your method here"accompanied by
me.SetEnabledThreadSafeMBS
me.SetMaximumThreadSafeMBS
me.SetVisibleThreadSafeMBS
for various controls. This avoids most of the spaghetti code with timers and whatnot.
Hi Trixie,
Thanks for this as it will be a quicker refactor than rewriting so many methods. I may follow up with you on this when we get back home later this week.
[quote=306635:@Tim Jones]Hi Sam,
Thanks, but since I already sub-class threads for my purposes, I’m not sure what I’ve missed there. What else might I be missing?[/quote]
hmm… Not a very well thought through suggestion perhaps…
When you perform a UI update; what kind of code do use? Can you include a snippet?
Yeah, sorry… my bad… Hopefully Tim can post some code and I can redeem myself??
Right at the moment, I’m refactoring code into master/worker apps as even with a thread there’s an API I use that hogs the primary thread until it’s completed… 