I know we’re not supposed to update GUI elements from background threads and generally we’d get thread exceptions if we try, but today in a fit of wanting to see if I could actually do it, or insanity, iE, add text into a text area from a background thread without the need of a timer to update the field with the text, I had a play around and actually did it.
Now I’m sure many have done this before and this is not news to anyone but it does works for updating any GUI element if you so code it.
Step 1: Add a UnhandledException Event handler to the App, Inside here catch and handle whatever you wish to do with the user error message you entered in the error you’re later going to raise.
For my purposes simply this:
[code]Try
Window1.TextArea1.AppendText(error.Message)
Catch e As RunTimeException
End Try
Return true[/code]
Step 2: In the run method or anywhere really of the background thread raise an error with the error message you wish to process, or print out in my case:
#Pragma BreakOnExceptions False
Dim e As New RuntimeException
e.Message = "Test Message from Thread." + chr(10)
Raise e
#Pragma BreakOnExceptions True
And that’s it really, as I said this is probably known by everyone, but I find it handy not to have to have a timer to update the GUI for simple stuff…
I have a sample little program to demonstrate this if anyone wants it. PM me and I’ll email it to you…
Why not? When I started programming many, many years ago, using custom error message was a frequent way of doing things, and using custom windows messages was pretty normal. Yes this was theoretical but it was still a fun experiment which others might find interesting, which can’t be a bad thing… Thinking outside the box once in a while can be fun…
Because I have a Pro license and the forum software says that if you have a pro license then this is the place for you. Move it somewhere else if you desire.
The “Pro” forum is the place where you place professional related questions and ideas that really pertain just to pro users - not stuff like this.
But your idea is absolutely a terrible one. Just because it works doesn’t mean you should use it. And it may work for you in this one isolated case. But the idea of doing this is just bad. Just because my card can operate at 100 miles per hour doesn’t mean I should drive it down the road at that speed.
First of all, threads can be overused. I had a lot of them in the past to do tasks that really could have been done no problem in the main thread. So do you really need the thread? Second, it’s pretty simple to create a thread subclass that has a built in timer for updating the UI whenever you want via an event handler.
It is a bit ambiguous as to where things should be posted at times, and I also choose he incorrect channel at times.
I’ve been using RB/RS/Xojo since 2004 and the forums since day one and I am still not sure what the purpose of the Pro channel is outside of consulting, job opportunities, and grousing about subscriptions, bugs, and release schedules.
Your question really would be better on the General channel since it and any discussion would be of interest to any Xojo user.
It is a bit ambiguous as to where things should be posted at times, and I also choose he incorrect channel at times.
I’ve been using RB/RS/Xojo since 2004 and the forums since day one and I am still not sure what the purpose of the Pro channel is outside of consulting, job opportunities, and grousing about subscriptions, bugs, and release schedules.
Your question really would be better on the General channel since it and any discussion would be of interest to any Xojo user.[/quote]
Thanks Tim, It wasn’t really a question merely the result of doing some experimentation which I believe that every programmer should play with from time to time. I merely wanted to see if I could do it and was excited enough to share the results. Is it the best way of doing this? Probably not and I never made any claim that it was, but it clearly seems that many on this forum don’t appreciate people trying things out of the norm. As I stated, many years ago using windows messages and custom errors was very common, but clearly not appreciated nor understood anymore. I feel quite concerned with the apparent toxic nature of this forum and once this thread disappears won’t be posting anymore. I have been using XOJO from when it was first called Real Basic and for the first time I feel upset that I paid so much to upgrade to the latest PRO version. I wish you all the best for the future, but please try to experiment from time to time. It can be fun, but not so much for me in this case…
I think its fun to try and experiment. In your case you not only shared your experience but you put it forward as a valid way to do things. We are saying its not a good idea.
Its not a good idea because you are violating specific standards and rules set up for good reason. A simple text field updated from a thread may not cause problems. But if you start doing multiple control elements and complex updates who knows what will happen or what sort of performance impact you will experience. Its just a bad idea to do something against what the OS manufacturers specify.
Just because something was used a lot in the past doesnt mean it is a good idea today. I first started learning TRS-80 Model III BASIC in 1983. Used a lot of GoTo statements. Thats not a good idea for today nor would trying to use cassette tapes to load a program.
I encourage you to have a thicker skin than you have shown. Nearly all of us have posted bad ways of doing something and have been educated as a result. I get schooled all the time by the people here on the forums and for good reason. If I tucked tail and ran every time an idea of mine was shot down, I would have left long ago and never learned as much as I have.
Trig, I don’t know if you know, but you can call out of a thread to update UI elements using a single line of code, no additional timers or logic is required in the target window, just create a method called UpdateLabel on your window that accepts an auto as a parameter then call:
Xojo.Core.Timer.CallLater(0, AddressOf UpdateLabel, "My message")
It’s a lot neater and easier than using exceptions or keeping track of/using timers on your main window, just don’t fire them too fast as they will queue and you will end up with the updates being backwards as the queue is lifo not fifo (probably a bug)
Also, don’t take much notice of the apparent “toxic” nature on the forums (not just this thread), like the tide it comes and goes. Try to bear in mind that a lot of people here don’t use English as their first language so a lot can be lost in translation. Some don’t have the time or interest to tread on eggshells or beat around the bush and lastly, not all programmers have a good emotional quotient (EQ) Chin up mate, don’t let it get to you, I’d have left a long time ago if it did
I participate in a lot of forums in a number of fields, and this is probably the least “toxic” of any of them - a great community of very experienced and knowledgeable people who are always ready to help others of any level, without attitude or condescension. Yes, people will come flat out and tell you if something’s a bad idea, but it should not be misinterpreted as hostility.
Using error control instead of a timer is inefficient, much slower, and very inelegant. There are issues attached. What if a real runtime exception occurs ? Then instead of controlling execution, your contraption will update the label. Are you sure that is what you want ?
It may work for now, but I would certainly never use that in production software. If and when Xojo comes up with multicore threading, it probably cease to execute as you expect.
I reread the whole thread and I fail to see anything toxic. The worst that was said was that it is a bad idea, so I think any toxicity is in how you read the responses, not in the responses themselves.
Its easy to feel offended when you dont get the (enthusiastic) response you were expecting, but that doesnt mean anyone was offensive.
I agree that it’s interesting as a curiosity and I think most everyone would agree that exploring non-standard approaches to things is good, especially when it reveals system behavior in edge cases.
I also agree that it’s unlikely that this GUI updating approach would be a good idea in a ‘real’ project where the goal is anything beyond experimenting with Xojo. It sounds to me like “experimenting with non-standard ways to do something in Xojo” was exactly what you were doing, so in that vein, I think it’s a cool find.
I hope I’m never in a situation where I have to resort to using that approach to updating a GUI, but I always enjoy seeing creative non-standard ways of doing things in case I’m in a weird situation and the normal approaches aren’t working–or in case it inspires ideas for other approaches.
