StringGadget and update, event queues?

[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?

[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.

[bsilver]

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?

[Axolotl]

Hey bsilver,

In general this piece of code by mk-soft could be helpful:
Mini Thread Control

[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".

[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 ...

[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?

[mk-soft]

See Mini Thread Control examples.

For this I have added AllocateString and FreeString ...

[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.

[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.

[jacdelad]

Hm, ok. Seems I was lucky to never have a crash or problem. Thanks for explaining.

[mk-soft]

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

[jacdelad]

Never experienced that...
Can a mod maybe delete everything starting with my faulty code? It isn't helpful for the initial problem.

[mk-soft]

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).

[jacdelad]

Great, now I'm a bad example.
But the idea with the disposable memory ist great and simple. Never thought of that.