FWIW this has nothing to do with being a professional or not
It has everything to do with how the OS’es expect applications to work - and this IS very different than it used to be under classic MacOS, Carbon, older versions of Windows and even Linux
All the OS UI frameworks basically expect to get back to the main even loop of the app and most redraw from that main event loop
So, when a action (like the code that does the sort) runs for some time & doesn’t have a mechanism to yield time back to the main event loop then drawing suffers
And this is exactly the symptom you see going on
It definitely requires thinking about how to do things like animations differently than you used to
Thing is, this kind of app has long been a stable of development language examples.
Ive seen the same thing rolled out in VB and Delphi in the past
It shows two things:
The comparative speed of the sorts, and then the speed of the compiler.
I saw someone’s example a few months back documented as ‘of course, it runs too fast today to see the animation’
But back in the day it was expected that the graphs would trickle away as the sorts were running.
Dont remember the VB code being peppered with DoEvents, but I wouldnt be surprised.
Thanks Norman. I will take a look at your example. Still seems, in my mind at least, keeping in mind the my career was all with IBM mainframe programming with PL/I, that it is idiotic that you cannot draw a bar and then issue some command that tells the OS to update it. I find it hard for anyone to think that that would not be an easier approach; but; as I stated earlier, I am an old dude with far less patience than what I had at the age of 21 when I started my programming career.
Never said that wasnt easier to deal with
Its just not how things work in modern OSes
UI updates happen on the main thread and this bit ocf code basically doesn’t let the main thread do anything until its done
So you only see that last thing drawn
Like Harrie, I’m not professional, I develop in my spare time. As I lost my job, then I decided to take a look in my 11 applications and remove all the DoEvents. I did 9 of them, 2 left (1 simple and the biggest one which I’m afraid to do).
3 of those applications are game. In the past, I did :
Calculate animation
MyCanvas.Refresh
DoEvents (because if not the Canvas doesn’t refresh)
Calculate next animation
MyCanvas.Refresh
DoEvents
and so on.
Now, I still don’t calculate the time of the animation, it goes as fast as it can, but if I have 10 animation, I do the 10 animations !
I have a thread.
Thread calculate animation.
Thread launch a Timer and go to sleep.
Timer do MyCanvas.Refresh and Resume the Thread
Thread calculate next animation.
and so on
On Windows, it was very very slow (previous it was fastest than on Mac). Then I replaced MyCanvas.Refresh by MyCanvas.Invalidate .
But if the Thread has a priority higher than 5 (the main Thread), then the Canvas was not completely refresh (only 30%). Then I put my Thread to priority 3 (less than Main Thread which refresh the Canvas), and it works as I want.
In the Xojo Doc they say it’s better to use Invalidate than Refresh because Refresh call to often may cause application to slow down. But when we use Invalidate we don’t know if the Refresh has been done or not. If I had an event “My Canvas has been refreshed” then I would resume my Thread in that event. I could do it in the Paint event, but this event fire and redraw only 30% of my Canvas, then it doesn’t help me, I need to know “my canvas has been redraw 100%”.
Harrie, yes it’s boring, yes I wanted to trash my application and stop to develop. But I reached to make it work and I’m happy. You will do it too.
And in very old version of Xojo (RealStudio), I’m not sure but I think that MyCanvas.Refresh or a Self?UpdateNow does refresh it even without a DoEvents after it.
Norman,
Thanks for the example. Looks like I need to create 12 timers, one for each sort algorithm and do a lot of moving of code in to those timer action events. I am sure that there will be the issuance of some wirty dords during the testing as a means of easing the frustration.
I still am a little lost here though. You state that this is how modern OSes operate and you are much much more informed here than me. The problem I am having regardless of which compiler option I am setting, 32 or 64 bit. The code is running in the same OS so that tells me that if it works in 32 bit and not in 64 bit the difference is that the 64 bit compiler is written to conform to these new standards and the 32 bit option wasn’t.
I have to admit, it was nice to see it run in 64 bit. Looks like I have to do somewhat the same thing for the non-animated version of the program because when I run it the results written in to the listbox showing number of compares, number of swaps and time to run do not get updated until the last of the chosen sorts completes. Looks like I will simply move the sorting code in to the action event of a timer and that way the respective line in the listbox will fill in when that each sort completes
I think I just may be seeing a very faint light way down there at the end of the tunnel now. Next big fight will be getting the UTI to work for my budget app; but, seeing as I am the only user of that app I just may have it directly open the file without an open dialog as a work around until the UTI thingy gets figured out. Have tons of dialog concerning that problem stored in the projects folder to help me out. Thanks again, and thanks to all that have tried to help this old guy.
[quote=354296:@Harrie Westphal]Norman,
Thanks for the example. Looks like I need to create 12 timers, one for each sort algorithm and do a lot of moving of code in to those timer action events. I am sure that there will be the issuance of some wirty dords during the testing as a means of easing the frustration.
[/quote]
Not sure that this requires that many timers
I literally just hacked the example project and reworked it to use a timer instead of a loop
I’m sure that each of the sort algorithms could be abstracted in a way that they each have a means of performing one “step” of the sort that can then be redrawn
[quote=354296:@Harrie Westphal]I still am a little lost here though. You state that this is how modern OSes operate and you are much much more informed here than me. The problem I am having regardless of which compiler option I am setting, 32 or 64 bit. The code is running in the same OS so that tells me that if it works in 32 bit and not in 64 bit the difference is that the 64 bit compiler is written to conform to these new standards and the 32 bit option wasn’t.
[/quote]
Apple doesn’t have the exact same code paths in the OS for 32 and 64 bit code
That much I’m quite sure of
Others, like Sam Rowlands, have reported other differences in Apple implementations between 32 and 64 bit
That would be a similar problem
The UI doesn’t update while running - only when it gets to the end of the code that is stopping the main UI from updating
I’m not exactly a “spring chicken” any more myself
I’ve started getting seniors discounts without even asking for them at some places
