Page 1 of 1
StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 3:14 pm
by bsilver
Still very new to using PureBasic, so this may help my understanding of the implementation of the language...
I have a form with a string gadget.
A button is clicked. This event is detected in the main thread, and calls CreateThread(@ConnectToSystem(),0), creating a new thread.
That thread is performing some network-related operations. Periodically it sends feedback to the user by calling SetGadgetText() to the string gadget.
The thing is I only see the text on that form jump from the initial text to the final text change at the end of the thread's run.
So I *think* that means that strings sent to that update operation...each of the SetGadgetText() calls...are being queued...and are then rapidly dumped when the thread exits. But it's a thread, so I don't know why the primary thread handling event loops isn't updating as the second separate thread is doing its thing.
Is there a way to get the queue processed to update that gadget? Or am I on the wrong track trying to figure out how PB works?
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 3:21 pm
by the.weavster
Only update the UI from the main thread. Use PostEvent() from any threads you've spawned to notify the main thread to perform the update.
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 4:25 pm
by bsilver
the.weavster wrote: Fri Aug 25, 2023 3:21 pm
Only update the UI from the main thread. Use PostEvent() from any threads you've spawned to notify the main thread to perform the update.
You're saying find a way to store the message in a scope visible to the main thread and use a postevent() call to have the main thread pick up the notification and execute the SetGadgetText() procedure?
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 4:27 pm
by Axolotl
Hey bsilver,
In general this piece of code by mk-soft could be helpful:
Mini Thread Control
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 4:33 pm
by jacdelad
Code: Select all
Enumeration #PB_Event_FirstCustomValue
#PB_Event_MyEvent
EndEnumeration
Global ExchangeString$,QuitThread,Thread
Procedure MyThread(Dummy)
Repeat
ExchangeString$=Str(Random(1000,0))
PostEvent(#PB_Event_MyEvent)
Delay(1000)
Until QuitThread
EndProcedure
OpenWindow(0,0,0,100,25,"Wargabl...",#PB_Window_ScreenCentered|#PB_Window_SystemMenu)
StringGadget(0,0,0,100,25,"")
Thread=CreateThread(@MyThread(),0)
Repeat
Select WaitWindowEvent()
Case #PB_Event_CloseWindow
Break
Case #PB_Event_MyEvent
SetGadgetText(0,ExchangeString$)
EndSelect
ForEver
QuitThread=#True
Repeat
Delay(10)
If Not IsThread(Thread)
Break
EndIf
ForEver
Compile it "threadsafe".
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 4:58 pm
by mk-soft
@jacdelad
It is not a good idea to use a global string, because a simultaneous reading and writing of the string can happen. Invalid String contents ...
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 5:07 pm
by jacdelad
Hm, ok, but this was just for the example. I usually use a Mutex, but shouldn't it be safe, with the option threadsafe and just these two processes using the string? I mean, the main thread has 1000ms to use the string...
Or asking in another way: How should I do this?
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 5:17 pm
by mk-soft
See
Mini Thread Control examples.
For this I have added AllocateString and FreeString ...
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 5:21 pm
by jacdelad
https://www.purebasic.com/documentation ... index.html
PureBasic has a special compiler setting to create thread-safe executables. (/THREAD command-line switch or "create thread-safe executable" in the IDE compiler options). Without this mode, certain functions (and also the string access) are faster, but not safe to use in threads. It is still possible to create threads without this mode but it is not recommended, as even something simple like a local string access can be dangerous and needs to be protected. Enabling this option makes these things save inside threads, but comes at the price of some speed. The decision on whether or not to use threads should therefore done with care, and the threadmode should only be used when there is a real need for it.
This sounded to me, that string access (which doesn't explicitely forbid writing) is safe with the threadsafe option.
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 5:28 pm
by mk-soft
That is not the point.
ThreadSafe is safe for strings, but you have to protect global string variables with semaphore and wait for the main thread to read the string variable.
Otherwise the string variable will be overwritten by the thread before the main thread has taken it over.
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 5:30 pm
by jacdelad
Hm, ok. Seems I was lucky to never have a crash or problem. Thanks for explaining.
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 5:33 pm
by mk-soft
jacdelad wrote: Fri Aug 25, 2023 5:30 pm
Hm, ok. Seems I was lucky to never have a crash or problem. Thanks for explaining.
No Crash, but invalid string contents or lost string contents
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 5:38 pm
by jacdelad
Never experienced that...
Can a mod maybe delete everything starting with my faulty code? It isn't helpful for the initial problem.
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 5:47 pm
by mk-soft
jacdelad wrote: Fri Aug 25, 2023 5:38 pm
Never experienced that...
Can a mod maybe delete everything starting with my faulty code? It isn't helpful for the initial problem.
It is helpful for others
As in my example, a string variable is created in the thread with AllocateString and the pointer is sent with PostEvent. In the main thread (WaitWindowEvent), the string is fetched with FreeString and the memory is released again. Thus the thread does not need to wait for the main thread (WaitWindowEvent).
Re: StringGadget and update, event queues?
Posted: Fri Aug 25, 2023 6:36 pm
by jacdelad
Great, now I'm a bad example.
But the idea with the disposable memory ist great and simple. Never thought of that.