gtafan wrote:Looks like the timer is not a perfect solution. I tried it, but in some situations it seems to behave like unsynchronized thread.
gtafan wrote:Since the background thread is working all the time the main thread exists, the user should still be able to use the application in every way. The background thread should just actualize some data from networck by doing some calculations with it.
If a timer can behave like an "unsynchronized thread" then there has to be some direct interaction between your two threads. Hence the question, if your main app is dependend on the results of the second one, or if it stays fully interactive all the time.
To my understanding, the user is giving parameters with the main app gui and the second thread/timer is using some network data + gui data to calculate and show something? In that case, no matter what you enter in your gui, every now and then the calculation should update or, as you said, "synchronize".
If your main thread "gui" app is dependent on that calculations of the second thread and therefore waits for the results of it, it's a different scenario.
gtafan wrote:The only thing I am not really understanding is about that events a background thread can send to the main application.
When using a timer, that timer is sending events to your main event loop and in that event function, you may do your calculations. When using a timer, your main thread should never pause (sleep, MessageBox or similar), or the handling of the event loop will be paused, too.
If you actually meant an event, ommited by your second thread, which should be handled by your main thread, im not sure what you are reffering to or why you would want to do that.
gtafan wrote:An other problem I noticed, after calling Delete() on the background thread, the main thread is not waiting untill it really deleted, but it needs to do so.
Looking into the docs, i find:
Calling Delete() gracefully terminates a detached thread, either when the thread calls TestDestroy() or when it finishes processing.
And diving into that, https://docs.wxwidgets.org/3.1/classwx_ ... d_deletion
Regardless of whether it has terminated or not, you should call Wait() on a joinable thread to release its memory, as outlined in Types of wxThreads. If you created a joinable thread on the heap, remember to delete it manually with the delete operator or similar means as only detached threads handle this type of memory management.
Since detached threads delete themselves when they are finished processing, you should take care when calling a routine on one. If you are certain the thread is still running and would like to end it, you may call Delete() to gracefully end it (which implies that the thread will be deleted after that call to Delete()). It should be implied that you should never attempt to delete a detached thread with the delete operator or similar means.
As mentioned, Wait() or Delete() functions attempt to gracefully terminate a joinable and a detached thread, respectively. They do this by waiting until the thread in question calls TestDestroy() or ends processing (i.e. returns from wxThread::Entry).
Obviously, if the thread does call TestDestroy() and does not end, the thread which called Wait() or Delete() will come to halt. This is why it's important to call TestDestroy() in the Entry() routine of your threads as often as possible and immediately exit when it returns true.
As a last resort you can end the thread immediately through Kill(). It is strongly recommended that you do not do this, however, as it does not free the resources associated with the object (although the wxThread object of detached threads will still be deleted) and could leave the C runtime library in an undefined state.
So, are you sure, you call periodically TestDestroy() in your second thread?
Delete does give you a return value (wxThreadError), which should be wxTHREAD_NO_ERROR (==0). If it is greater 0, you can evaluate your error by checking the output (https://docs.wxwidgets.org/3.1/interfac ... 3035f75ac2
No resource left to create a new thread.
The thread is already running.
The thread isn't running.
Thread we waited for had to be killed.
Some other error.