nanogui: PeekMessage and other questions
Subject:
Re: [nanogui] PeekMessage and other questions
From:
"Greg Haerr" ####@####.####
Date:
31 May 2001 02:03:51 -0000
Message-Id: <083301c0e96d$4f44f440$3aba46a6@xmission.com>
: 1. Is the Nano-X API in some sense the preferred API, since more people on
: this list seem to be using that than the WIN32 one? Plus of course the
: multiple-app benefit of Nano-X. I wonder, is there functionality that
: Nano-X is capable of, and which the WIN32 API will never be able to do?
I started with the WIN32 API, since it actually does have a few benefits;
however, getting multiple-apps to work with it will require a marshalling
implementation, and bringing in a midl compiler which isn't worth the
effort currently. Because of that, I switched efforts into completing
the Nano-X API. The NX API's biggest benefit is that it's very close
to the X API (although ugh the names are all different...) This nonetheless
allows Xlib Linux programs to be brought over (although the color model
is completely different)
:
: 2. I take it that menu/menubar functionality in the WIN32 API must be
: provided by the application since this part of the API seems to be missing
: in MicroWindows.
There are currently only about 6 or 7 "custom controls" built into
the WIN32 API. Adding menus isn't that much work, but tedious.
You may be able to borrow an implementation from the Wine or
MiniGUI projects. Also, I would like to add .RES file support.
:
: 3. PeekMessage appears to do the wrong thing, because if the message queue
: is empty, it'll still call MwSelect and (as I understand) wait for input.
: This means that a message loop that makes use of PeekMessage won't work. I
: think the fix is quite simple, e.g. copy PeekMessage to a function called
: PeekMessageHelper with an extra bool argument returnIfEmptyQueue, which can
: be called by PeekMessage with returnIfEmptyQueue = TRUE and by GetMessage
: with returnIfEmptyQueue = FALSE. If returnIfEmptyQueue is TRUE and the
: queue is empty, PeekMessageHelper returns before MwSelect is called (it has
: to avoid the MwSelect in chkPaintMsg too). If that makes sense!
I guess I fixed this for NX but not for WIN32. You're proposed fix is OK,
but still not completely bug-free. That is, when there are no messages and
the user wants a PeekMessage(), you still need to call MwSelect() with
a 0 timeout (meaning poll). Otherwise, you'll never read any message
that comes in for the PeekMessage()-polling program. A quick way
to fix this would be to pass MwSelect() a timeout argument based
on the PM_xxx value from GetMessage or PeekMessage().
Regards,
Greg
