I do appreciate Xojo examples because indeed they are no frills code, and no unnecessary stuff that can obscure comprehension.
I had a taste of just the opposite with the print sample that is supposed to help poor souls with VB and UWP apps new API. That stuff is so convoluted, made of such an intricacy of subroutines, that I could never get to the heart of it. I gave up after wasting a full week on it. As if the author had purposely made it complex to prevent reverse engineering.
After I let my frustration show in their forum, all they could do was asking me to have a more positive attitude. 3 years later, their example is still unusable.
I know that some of the more common compliments I get in the training videos are a) showing what our standards are. b) defensive coding techniques. c) Showing how I correct mistakes (after I make them which is more often then I’d like to admit). Another part of the benefit of the training videos is that I’m talking about why I’m doing things as I’m doing them which you’d never get from the source code examples.
A lot of commercial videos are scrubbed to eliminate the mistakes. Newbies don’t learn how to recover from mistakes because they’re never taught how to use the debugger, put breakpoints in, etc.
The short and quick examples should be pretty straightforward. However, bigger example apps (like Eddies Electronics) should be coded to standards with defensive coding with a crap ton of comments to make it clear what’s going on. I don’t agree with every line should have a comment but a newbie should be able to understand what’s going on in an event/method when looking at the code.
Me.Sleep should only be used in a thread and ONLY affects the thread that it’s called from.
App.DoEvents will run on the main loop, but is strongly frowned upon outside of a more procedurally oriented Console app since it can cause unexpected recursion in an event-oriented desktop app.
The best replacement for a loop that otherwise would require App.Doevents to avoid freezing the UI, is to use a multiple timer as loop.
Sub Action()
Static count as Integer
Static Start as Integer = 1 // First argument in a For loop, ie For count = Start to Max
Static Max as Integer = 10 // Last argument in a For loop
Static StepValue as Integer = 1 // As in : For count = Start to Max Step 1
if count <= 10 then
// Do whatever you would have in the loop
//...
System.Debuglog str(count)
count = count + StepValue
else
me.mode = Timer.ModeOff
end if
End Sub
Instead of Static, one can also use Window properties.
Note that the problem the OP faced was not mistaking that atrocious little loop as good or even useful code. It was wondering why does this example burn so much cpu? And is that indicative of Xojo’s performance in general? I think we answered that question.
That said, I think example code should be sparse and to the point. It is intended to demonstrate how a single function works and shouldn’t be weighed down by any but the most relevant error checking. But I would definitely be in favor of expunging that stupid loop from the example.
Greg will probably chime in, but since Web apps are basically dressed up Console, App.DoEvents may not have the same detrimental effects.
In Desktop, I have removed any App.DoEvent for years, and use primarily timer loops, less often threads because they require more overhead. The nice thing about threads, though is that in there, you can actually place a tight loop and it will not freeze the UI.
WE apps provide an event loop for you, so, no, it is not ok to call DoEvents again. You face the same issues you would in a desktop app. If DoEvents solves a problem, then it’s time to refactor using timers or threads.