PureBasic Forums - English

Hello Forum.

Maybe this has been discussed in the past, it didn't touch me as I found a good solution for me which worked perfect in the past. Unfortunately since 5.30 this method is not allowed any longer.
This is what I have done:
In every thread I used a Window-Element with a windows message queue and an event loop as nearly same as in the main thread. If I share data between those threads I just allocated a bunch of memory (a predefined structure) and send a user defined message (using PostMessage) to the window object of the thread holding a pointer to the buffer.
After the message was processed within the thread the memory gets freed up by the thread. Same in the other direction.

Since 5.30 it is no longer allowed to create windows within threads, even no gadgets and so on. This leads to a big problem for my projects. (Disabling the debugger helps at that point, but maybe will lead to problems later I want to avoid)
GUI which is created in threads now needs to be placed in the mainloop somehow, big code restructure is required, new elements and lists/ maps are in need to handle the amount of dynamic elements (windows, Gadgets) within the mainloop increasing the overhead in the mainloop.

ATM I cant see a good solution how to handle the communication to the threads and from the threads to the main thread.

Anyone have hints in this direction?

Maybe you could just setup the structure a bit differently.

You could setup 2 more fields to it stating each the source and destination of the rest of the message, being source the thread/mainloop constant, and destination the one you want to pass the information for.

This is the sort used for point>multipoint communication.

Hi Deesko.

Thanks for trying to help, but I cant follow you.
How does the running thread knew, that there is a message to pull and where?

I searched the web and I found this article on MSDN which explicitly allows the creation of windows in threads.
Fred & Team, why has it changed? Its a big step back for coders who are in need of threads in windows.

ATM I must keep 5.2x LTS. (Good to see that this is a LTS version!)

This problem seems not to be new in PB 5.30.
Maybe this recommendation by Fred will help you.

Oh dear... so the introduction of an debugger message is just the new thing.
This should be mentioned in the docs for CreateThread(). ATM there is only a spot on DirectX drawings.

Sure I can post a message to the main loop, but how to send a message back to the thread? The windows message queue was so easy to handle.

At first the thread need to notice, that there is a new message somewhere. Yes that can be a global list which holds messages for all dynamically created threads, I then have to use Mutex objects to lock the list and search for new messages for each thread which is created. CPU bloating and slow when it comes to more threads.

Tranquil wrote:Yes that can be a global list which holds messages for all dynamically created threads, I then have to use Mutex objects to lock the list and search for new messages for each thread which is created. CPU bloating and slow when it comes to more threads.

Yes that's actually what I meant. Maybe you could start by creating an array of the same structure * (number of threads + mainloop).

Let's see it in action:
Now each time one thread needs to send something to another specific thread (or mainloop), it goes into the index reserved for that destination and fills in it's own constant thread index in Source, and fills in the Info to send.

Then, the other threads just need to poll it's own Index in the array, and if there's a Source filled in, it just sets the Source back to 0 and retrieves the Info, and then it goes all over again.

That's probably the better way to deal this problem.