> Actually, local testing here shows that the FIRST click of a 
> window that
> DOES NOT have the "focus" brings the window to the top but 
> does NOT move
> the terminal cursor to match the mouse pointer.  The SECOND 
> click, however,
> moves the terminal cursor to the mouse position.

The behavior is determined by the application. The commonly-accepted way
to handle this is as you describe, i.e. activate the window but
otherwise ignore the mouse action. However, the application must be
programmed to respond that way.

For the tech weenies in the crowd (like anyone who might want to change
the way their software operates): the message received by your window
proc is WM_MOUSEACTIVATE. To get the behavior described, i.e. activate
but otherwise ignore, you must return MA_ACTIVATEANDEAT. If you return
MA_ACTIVATE, the window will be activated, and will then receive the
WM_[NC]xBUTTONDOWN message corresponding to the mouse activity (the
to-be-generated mouse message is in the HIWORD of the lParam of the
WM_MOUSEACTIVATE message). There are also NOACTIVATE versions of the
return values if you don't want your window to become the active window.
More importantly, the NOACTIVATE version *must* be used when a parent
window receives the message on behalf of a child window (from the
child's DefWindowProc) and wants to control the result (by either
activating the child or not). The NOACTIVATE return is required to turn
off further processing of the message; this is similar to the
requirement that a parent window that receives a WM_SETCURSOR on behalf
of a child window and selects the cursor must return TRUE to keep the
message from being passed on.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *