void Ctrl::Create0(Ctrl *owner, bool redirect, bool savebits) { GuiLock __; ASSERT(IsMainThread()); LLOG("Create " << Name() << " " << GetRect()); if (IsChild()) LLOG("Ctrl::Create0 IsChild = True"); if (IsOpen()) { LLOG("Ctrl::Create0 IsOpen = True"); Close(); // HACK } ASSERT(!IsChild() && !IsOpen());
void Ctrl::Create0(Ctrl::CreateBox *cr) { GuiLock __; ASSERT(IsMainThread()); LLOG("Ctrl::Create(parent = " << (void *)parent << ") in " <<UPP::Name(this) << LOG_BEGIN); if (IsOpen()) { LLOG("Ctrl::Create0 IsOpen = True"); Close(); // HACK } ASSERT(!IsChild() && !IsOpen()); ...
void Ctrl::Create0(Ctrl::CreateBox *cr) { GuiLock __; ASSERT(IsMainThread()); LLOG("Ctrl::Create(parent = " << (void *)parent << ") in " <<UPP::Name(this) << LOG_BEGIN); if (IsOpen()) { LLOG("Ctrl::Create0 IsOpen = True"); Close(); // HACK } ASSERT(!IsChild() && !IsOpen()); ...
Quote: |
The root of problem is stupid M$ decision that binds windows and event loops to threads. That makes practically only possible to create windows and run event loops in the main thread. |
Quote: |
Alternatively, I am starting to thing that perhaps easiest is to ban creation of windows in non-main thread (Prompts could perhaps be supported as exception, DisplayPopup::Sync would have to be rewritten). |
Quote: |
The root of problem is stupid M$ decision that binds windows and event loops to threads. That makes practically only possible to create windows and run event loops in the main thread. |
Quote: |
Anyway, I wonder, would it be worth to ask how M$ does it? In other words, how a pure M$ app is supposed to be developed so that it does what I want without crashing? I mean, is there some M$ recipe for creating new windows not in main thread and still be able to run event loops in it without crashing? I don't know, maybe such an investigation could bring up new insights on which course to take to fix the problem, for I guess purely M$-based progs must end up having to do it one way or another. |
Quote: | ||
If you decide to do so, does it mean we will no longer be able do stuff like adding Ctrls in a background thread dynamically, while 'simultaneously' enabling user interaction with GUI, or would new DisplayPopup::Sync code otherwise still make it possible? |