Hi all,
I admit that I’m struggling trying to find a solution to this problem. Let me
expose the question in a different way:
I’ve a BWindow where I add a BGLview to it and just handle the Pulse function.
Inside the pulse function I do everything needed to allow my system to loop and
respond to events etc…
CustomBGLView::Pulse()
{
engine->Loop();
}
I also reimplemented MouseDown, MouseUp etc… to catch those events and send it
to my system queue that later will be processed in the above Loop() function.
It can happen that inside the Loop function at some point I need to start and
infinite loop to lock a function and avoid it to return (mostly to call the
modal window I mentioned in the previous email), this is some sort o pseudo
code to make it simple:
Int do_modal()
{
int val = ...
// Some initialization etc…
...
while(running)
{
// Here is where I call the OS’s message loop so the OS can
continue capture messages and forward it to main window.
// This will allow the system to go back again to the
engine->Loop() function and everything will continue to work while still here
// waiting until running will be set to false.
// In Windows it is:
while(PeekMessage (&msg, NULL, 0, 0, PM_NOREMOVE))
{
if(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
// In Linux it is:
while(XPending(disp) > 0)
{
…
}
// In macOS
NSEvent *event = [NSApp nextEventMatchingMask:NSAnyEventMask
untilDate:nil inMode:NSDefaultRunLoopMode dequeue:YES];
[NSApp sendEvent:event];
[[NSRunLoop currentRunLoop] runUntilDate:nil];
// And other similar mode in other OS
…
// Haiku?
}
return val;
}
As you can see I do not create any OS specific window/dialog in the do_modal
function (that’s why the BAlert solution it is not useful in my case).
Actually I tried in so many ways and I tried to follow the Haiku source code to
see how app_server dispatch messages to a target, but still I’ve not come to a
solution yet.
I can of course change the way my system handle this scenario, but it will
require changing a lot of code base and, if possible, I want to avoid it.
So, is there a similar way to handle a situation like the one above?
Many thanks again for your time,
Carlo
Il giorno 14 nov 2022, alle ore 13:43, Carlo Lanzotti
<clanzotti@xxxxxxxxxxxxx> ha scritto:
Hi Zenja, Axel,
Thank you very much for your reply.
Tried the solution found in the BAlert:Go, but still something is not going
the way I expect. Now I’m able to dispatch asynchronously UpdateIfNeeded()
but still my underlying view (a BGLView) does not receive messages. Same for
the main window that remains locked even if the messages are supposed to be
sent to it (can’t be maximized nor quitted with the standard title bar
buttons).
Am I missing something else?
Regards,
Carlo
Il giorno 14 nov 2022, alle ore 08:08, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
ha scritto:
Am 13.11.2022 um 22:56 schrieb Zenja Solaja:
I understand your issue, and wont bother discussing the merrits of
blocking. The easy way is to use the B_MODAL_WINDOW creation flag. See
BAlert source as an example.
That's indeed a good example; BAlert::Go() does pretty much what you want.
It waits for the window to close without suppressing window messages.
If you look at the implementation of BWindow::UpdateIfNeeded(), it looks
pretty similar to the sample code you provided.
Bye,
Axel.
