Guys I am a new user to Xojo, I love this IDE, I value and appreciate how much effort and attention to detail has been put in to making the dev experience as simple and easy as possible but I am having an issue with being able to refresh / redraw controls and or the entire window. I have tried using timers and using methods (sub procedures ) I have tried of course the all the normal approaches as well such as control.refresh, me.refresh, window.refresh etc… but no luck I can not get the controls to refresh unless the code is completely finished executing. I understand that this software is very similar to how vb 6 was back in the day but even the app.doevents() isn’t getting the job done. I deeply deeply want to write my next project in this IDE but If am forced to use a bunch of timers and such just to get a few controls to update during code execution then this is one HUGE flaw in the IDE and would turn alot of people away. I do not want to see that happen to what I believe is the BEST IDE out there. Please help me understand how to update my controls IN THE MIDDLE OF CODE EXECUTION not when only completed. Thank you guys for any help and advice.
I am coding on a linux box building to a target of linux currently.
Have you used the Examples that come with Xojo?
Maybe the ones using threads and how to update the UI is what you need.
If you can share some sample project I’m sure you will get feedback on how to improve it.
You can share your project using Dropbox, Google Drive or other sharing service and pasting the link in the forum.
Any code you run from a timer / user event (ie: button click) runs on the main application thread. The main application thread is also used by the operating system to process events / update the screen. This means that while your code is running, no events can be processed so the effect of updating the UI won’t be seen until your code has finished. Blocking the main thread for too long also invokes the application not responding feature of the operating system.
NOTE. This isn’t a limitation of Xojo and you will see this with other development environments.
The solution is to put your long running code into a thread which can then use a mechanism to update the UI while it is running. At least one of the Xojo examples demonstrates this.
Using DoEvents is the wrong solution (its only really for console / service applications) and will lead to weird behaviour.
Kevin G thanks for a more verbos reply, can you point me to an example from xojo, like an example project name that would the best to reference that truly demonstrate this clearly?
If you’re doing any time-consuming calculations, that should certainly be done in a thread. In general, event handlers should avoid long running work and be kept as short as possible. Anything that involves a wait (such as for data from a remote device or host) should also be done via threads. That way you keep the UI repsonsive, and it makes the code handling such things more straightforward.
In general terms , lets say you have a routine that calculates 4 million values, and wants to update the display to show what percentage has been done.
Remove all UI handling from the code
Add a property to the window : PercentageDone
In your code, periodically update that variable with DoneSoFar/4million * 100
Add a thread
In the tread.run action, call your long running code
Start a timer to multiple
In the timer, set the value of a progress bar to be the PercentageDone, and invalidate it
If the thread has stopped running, kill the timer
When people that have worked for Xojo and should know how things work say something like don’t do this or that, I usually try to follow what they say (for example this from Greg):
There have been several answers telling that using DoEvent could do strange things, be not debuggable or should be avoidable, true. But I’ve yet to read one single case where an issue was really encountered.
It’s also usually said one who uses DoEvent without crash just has some luck. All these comments tend to say DoEvent produces mysteries, uncontrollable behaviours, but lack a description of “why”. And I tend to not believe things just because it’s said that way.
In other words, we’ve never seen a single proof .
I have been a big fan of DoEvents. But the problems it caused me over the years… yikes.
It becomes more apparent when you have several windows open at once.
If your app is a single dialog, youre pretty much safe, I feel.
But ‘things happening somewhere you dont expect at a time you dont expect’ can cause nasty things to happen.
Like controls you expect to exist to be nil for a moment or two, or ‘things happening in the wrong order’ so variables are not initialised in time.
So yeah, you can get away with it. Sometimes.
As someone that knows a bit about how things works behind the scenes, I can say that overriding the event loop, activating the event processing from a random place, in a random moment, can lead to unpredictable behaviors like a DEL key pressed deleting something in a improper time in a unexpected field, a window that should be open to close, a window that should be closed to open, something that should not fire until finishing the current job will fire before the current job, lots a possible wrongdoings because of events firing at improper moments and order. Someone with advanced understanding of what’s going on can take some “kind of safe” use of it? Kind of yes… Do I know some user saying that it is safe to use it, having such kind of knowledge? No. I don’t.
I want to tell everyone thank you for giving your honest opinion on this topic. I am glad to see there are other developers out there who are not afraid to admit that they also like take advantage of the App.DoEvents method. It’s how UI refreshing should be. So simple. When it comes to WinForm style of Development lets be honest with each other and not be afraid to admit that if there was a way for Xojo to create such a method to update a single control, list of controls, container of controls, or the entire form of Wow what a game changer that would be! If Xojo Devs can handle these mysteries that arise from using App.DoEvents method that we all love to use, wow what a feature us Dev’s would love to have and worth investing in and tackling. It is very clear just from this one posting thread that developers desire and wish to use such a method everywhere in their apps to update their UI at any point in time of code execution they choose. Don’t make it hard, just process my change to the control and update/refresh the control now. easy peasy lemon squeezy, should not be any harder than that. I know that there are reasons why you should do it with timers and sub procedures but we should never be afraid of what if… what if, Xojo could tackle those anomalies and add this as feature and make the best IDE out there, even better. Also sometimes its just best to let the Dev deal with their own decisions and account for the mysterious/anomalies/timings of control refreshes themselves in code.
it looks like this
Main Loop → UI Update → Events → YourMethods
if you are inside of a method no other events occur.
for small delay use mouse pointer wait.
for sequence of task process it one by one not in a single loop.
as example 10x a task with 1 second duration will in a loop block the event loop for 10 seconds,
but processing it one by one you will see at least an ui update after 1 second.
otherwise use thread or worker.
.