Unexpected Return

General
1

I was calling methods from another method, relying on Return to take me back to the correct location inside the method making all of the calls. Upon returning, a call to another method is made.

This worked fine until I needed to run a thread from this method as well. Now the thread is called and the calling method is immediately returned to while the thread is still actively processing.

Any suggestions as to how I can keep this from happening or a better concept of dishing out these calls?

Thanks.

2

You can’t really keep it from happening. Thread calls are asynchronous. You’ll want to rethink your design.

One technique would be to start a Timer before you start the thread. Have the timer check if the thread has finished and when it has finished, stop itself (the timer) and then call the method you want called at thread completion.

3

Threads run asynchronously
So if you do something that would start a thread & run it expecting to wait until its done then you probably have to split your code into bits that can start the thread and a portion that gets started once the threads Run event exits (as its done its work)

4

How do you think theads should work?

If you want something to work like a method then you should use a method, not a thread.

5

If you need part of it threaded because it locks up the UI, put all of it into a thread. Which is easy, because you can simply call the main method from Thread.Run and voila! the whole thing’s threaded.

6

There are times when you want an event to run synchronously with a thread. This is easy to do:

 FileSaveMenuHandler
  threadIsRunningFlag = true
  Thread1.Run   // note: thread1 must clear threadIsRunningFlag 
  While  threadIsRunningFlag
      app.sleepCurrentThread(100)  // will check 10x per second to wakeup
  wend
  msgbox "File's Done!"

The reason to use this technique is when you want all other events to be blocked while this one completes.

7

[quote=185023:@Michael Diehr]There are times when you want an event to run synchronously with a thread. This is easy to do:

 FileSaveMenuHandler
  threadIsRunningFlag = true
  Thread1.Run   // note: thread1 must clear threadIsRunningFlag 
  While  threadIsRunningFlag
      app.sleepCurrentThread(100)  // will check 10x per second to wakeup
  wend
  msgbox "File's Done!"

The reason to use this technique is when you want all other events to be blocked while this one completes.[/quote]

Forgive me, Michael, but I fail to see the use of a thread which ties the main thread while it is not finished. Is it not precisely the goal of a thread to uncouple execution from the main thread ?

8

Michel, good question.

Have you done a lot of realtime UI programming? It makes sense when you imagine that there are other threads doing important tasks too.

Suppose you have an “earthquake monitor” app. It needs to monitor earthquakes, so that runs on background thread “A”. It’s important to capture all data.

But, this app allows you to configure the settings. You can save the settings. Say the user makes some changes, then clicks “Save”.

What should happen?

You could run the “Save” routine in the event loop. Works great, except thread A is blocked, and you miss some earthquake data.

Or, you could run the “Save” routine in Thread B, and just fire this off asynchronously from the Event loop (e.g. you return immediately from the Event loop, and other Events such as mouse clicks or menu handlers can fire). This works fine, until the user modifies the settings during the Save routine. That’s not good.

One logical solution: Let thread A run, and do the Save in Thread B, but, also, block the Event loop so that other UI is blocked until thread B finishes.

Conceptually, you are using the Event loop as a Semaphore.

9

I went with Tim’s solution for now. I think I really need to just recode, but this is allowing me to see most of what’s going on for now.

There are many places in the code that are updating labels on the main window to show information on processes and progress. As I understand it, this shouldn’t be done from within a thread.

Fun…

Thanks for all the input.

10

[quote=185052:@Michael Diehr]Michel, good question.

Have you done a lot of realtime UI programming? It makes sense when you imagine that there are other threads doing important tasks too.

Suppose you have an “earthquake monitor” app. It needs to monitor earthquakes, so that runs on background thread “A”. It’s important to capture all data.

But, this app allows you to configure the settings. You can save the settings. Say the user makes some changes, then clicks “Save”.

What should happen?

You could run the “Save” routine in the event loop. Works great, except thread A is blocked, and you miss some earthquake data.

Or, you could run the “Save” routine in Thread B, and just fire this off asynchronously from the Event loop (e.g. you return immediately from the Event loop, and other Events such as mouse clicks or menu handlers can fire). This works fine, until the user modifies the settings during the Save routine. That’s not good.

One logical solution: Let thread A run, and do the Save in Thread B, but, also, block the Event loop so that other UI is blocked until thread B finishes.

Conceptually, you are using the Event loop as a Semaphore.[/quote]

I would rather disable the button or menu item that initiate the save than the whole UI. Having a thread block another feels improper to me.

Earthquakes bad.1994 Northridge earthquake. My whole neighborhood shattered. Bad.