nanogui: Thread: PeekMessage and other questions

Hi,

I'm looking at the MicroWindows APIs and have one general and two specific 
questions/comments.

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?

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.

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!

Julian
--
Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1 
7EG Tel: +44 (1223) 271063

If you have some changes, send in a patches to either the list, or 
####@####.#### in particular.  

Jordan

 hOn Friday 25 May 2001 08:24, Julian Smart mentioned:
> Hi,
>
> I'm looking at the MicroWindows APIs and have one general and two specific
> questions/comments.
>
> 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?
>
> 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.
>
> 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!
>
> Julian
> --
> Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1
> 7EG Tel: +44 (1223) 271063
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

: 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

At 07:02 PM 5/30/01 -0600, Greg Haerr wrote:
>: 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)

Thanks for the explanation!

It occurs to me that using an OS such as eCos, where we would replace 
processes with threads anyway, the marshalling wouldn't be required, though 
we would need to protect the WIN32 API adequately from unwanted reentry. 
Maybe it would be worth adding pseudo-multi-app support under Linux too, to 
make the WIN32 API applicable to more users until real multi-app support is 
there.

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

I've just heard that the wxUniversal port project has just got their menu 
implementation working...

Regards,

Julian
--
Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1 
7EG Tel: +44 (1223) 271063

At 07:24 PM 5/31/2001, you wrote:
<snip>
 >I've just heard that the wxUniversal port project has just got their menu 
implementation >working...
</snip>
Since we're on the subject of menus here, I would like to know if anyone 
has managed to use the menu implementation provided with TinyWidgets. (It 
wouldn't work with the *old* nanowm due to some focusing issues - Amit had 
a patch for that). Will there be an improved nanowm implementation 
available with the latest source (that Greg is gonna release soon) ?  

: It occurs to me that using an OS such as eCos, where we would replace 
: processes with threads anyway, the marshalling wouldn't be required, though 
: we would need to protect the WIN32 API adequately from unwanted reentry. 

There's still the problem that SendMessage() has to execute in the
context of the receiving thread in it's WndProc(), but it might not
be that bad, since all addresses would remain valid.

Regards,

Greg