Up to now, the only allowed interaction with non-main threads and GUI was through sending events.
The new approach introduces "Ctrl::EnterMutex" and "Ctrl::LeaveMutex" methods that can be used to protect shared access to any widget (and helper class Ctrl::Lock that does so on for block using contructors/destructors).
Means accessing widget data or changing widget content in non-main thread is now much more simple.
For now (maybe only today , there are certain methods that cannot be called by non-main thread - those that deal with opening new windows and events (event loops). It is because in Win32 it is impossible (for U++) to run them in any other thread than main.
I will probably resolve this situation by performing such requests in main thread.... (via new planned "Ctrl::Call function that will make possible to 'call' code in main thread while waiting for its completition).
Actually, there is single mutex for everything. That is required by X11 anyway and semi-required by Win32.
In fact, after some thinking, I have decided to scratch the idea of "per widget" locking and replace this global mutex available.
Also, Ctrl::Call is now implemented and thus you can absolutely anything in threads with GUI (but some things are being performed in main thread using Call).
So the final rule for MT GUI programming is pretty simple:
If you are going to call any method or GUI function, you have to lock the scope using GuiLock helper guard (or EnterGuiMutex/LeaveGuiMutex pair).
Members
Pages
Help
Register
Login
Home
, there are certain methods that cannot be called by non-main thread - those that deal with opening new windows and events (event loops). It is because in Win32 it is impossible (for U++) to run them in any other thread than main.
