Progress wheel stays invisible

It just does that. It’s not for a commercial applictaion, so no sweat.
BTW - everybody is constantly learning. Even you… (maybe not Realbasic, that what it was called when I was a beginner)
:wink:

[quote=385558:@Peter Kronenberg]It just does that. It’s not for a commercial applictaion, so no sweat.
BTW - everybody is constantly learning. Even you… (maybe not Realbasic, that what it was called when I was a beginner)
;-)[/quote]
Version 3.5 when I started.

I’m not saying I have nothing to learn, I’m saying I have learned this and I’m sharing the knowledge. There is already an event loop running in your example code. It’s the built-in one always running.

DoEvents was intended exclusively for console apps, where you need to run the event loop yourself. It was part of the desktop framework because there wasn’t a way to limit a method to certain frameworks at the time. The only reason it doesn’t get removed is to prevent breaking legacy code (though I’d argue it’s already broken) and because synchronous HTTPSocket requires it. The IDE uses it too during the loading screen IIRC. That’s not an excuse though, as those parts shouldn’t use it either, but it doesn’t get removed because old, bad code requires it.

But writing new code which relies on it, especially when you know the “right” way? That’s intentionally dangerous.

I think it was 3.5, too, 2002? :slight_smile:
Ok, thanks Thom, then I would like to remove it, but name me an (almost) easy way to get the same effect: Make it appear and disappear at that very moment, not until the program becomes idle. Thanks!

As I suggested April 25th. The right way to do it is to get your time-consuming work off the main thread.

Here’s a very simple subclass of Thread which adds events for pre and post execution. Drag this to your window, put your time-consuming code in run, and progress wheel code in the pre/post events.

[code]#tag Class
Protected Class Task
Inherits Thread
#tag Event
Sub Run()
RaiseEvent Run()
Xojo.Core.Timer.CallLater(1, AddressOf PostRun)
End Sub
#tag EndEvent

#tag Method, Flags = &h21
	Private Sub PostRun()
	  RaiseEvent PostRun
	End Sub
#tag EndMethod

#tag Method, Flags = &h0
	Sub Run()
	  RaiseEvent PreRun()
	  Super.Run()
	End Sub
#tag EndMethod


#tag Hook, Flags = &h0
	Event PostRun()
#tag EndHook

#tag Hook, Flags = &h0
	Event PreRun()
#tag EndHook

#tag Hook, Flags = &h0
	Event Run()
#tag EndHook


#tag ViewBehavior
	#tag ViewProperty
		Name="Index"
		Visible=true
		Group="ID"
		Type="Integer"
		EditorType="Integer"
	#tag EndViewProperty
	#tag ViewProperty
		Name="Name"
		Visible=true
		Group="ID"
		Type="String"
		EditorType="String"
	#tag EndViewProperty
	#tag ViewProperty
		Name="Priority"
		Visible=true
		Group="Behavior"
		InitialValue="5"
		Type="Integer"
	#tag EndViewProperty
	#tag ViewProperty
		Name="StackSize"
		Visible=true
		Group="Behavior"
		InitialValue="0"
		Type="Integer"
	#tag EndViewProperty
	#tag ViewProperty
		Name="Super"
		Visible=true
		Group="ID"
		Type="String"
		EditorType="String"
	#tag EndViewProperty
#tag EndViewBehavior

End Class
#tag EndClass[/code]

And of course, there’s Xojo’s built-in Task class, which is very easy to use (probably exactly the same as what Thom wrote out, but the docs page makes it a lot easier to understand).

http://developer.xojo.com/task

[quote=385573:@Julia Truchsess]And of course, there’s Xojo’s built-in Task class, which is very easy to use (probably exactly the same as what Thom wrote out, but the docs page makes it a lot easier to understand).

http://developer.xojo.com/task[/quote]
True, but just FYI it’s not built-in. It’s a language reference entry for the example project referenced near the beginning of this thread.

My quick example is exactly that: quick. It doesn’t handle progress and assumes that .Run will be called from the main thread. The point was that this problem doesn’t need to be difficult or technically even require a subclass.

Right you are! Once you put it in your project, it feels built-in, though :slight_smile:

sigh…

Here’s an example. You have a PushButton with an Action event

for i = 0 to Ubound(somearray)
    // set up the global environment
    app.DoEvents   // update the display
    // processing based on the global environment just set up
next

If the user clicks the button twice, then the entire loop will run again inside the DoEvents call, causing the enviroment to be completely different after DoEvents and causing your code to do unexpected things, like dying in a fiery crash.

That’s a Bad Thing!

Thanks for all your help - will knee into it, when I have enough spare time.

Would you mind unmarking your answer? It would be a shame for newer users to see that answer and think it’s the right one.

I think, what @Thom McGrath want’s to say is: “Yes, DoEvents works in Desktop Apps. But it’s really a NO GO for Desktop Apps.”.
DoEvents is really meant for Console Apps and Xojo Inc. should disable it for Desktop Apps.

If you want to build solid Desktop Apps, stay away from DoEvents. Threads are not that hard to handle. The more you work with em, the more you’ll like em. :smiley:

I will never quite understand why people are so afraid of using timers. Then they resort to dubious programming techniques, and wonder why their software crashes for no apparent reason.

Michel it’s just for the excitement and tension just as with oldfashioned russion roulette :smiley: