> > So it's writing this to the non-client area directly.I can't see how
> > managed mode will ever support this.You'd somehow have to hack
> > GetDCEx to return a special dc if we want a DCX_WINDOW dc.This dc
> > would have to trap attempts to draw stuff to the non-client area and
> > somehow persuade the Window Manager to draw them...
> >
>
> That was the general feeling. In that case there are several
> questions:
> 1. What should be done when a client is writing to a non-client area?
> It is wrong to put it in the client area (the way it is done now).
> Your suggested hack works when the string is few pixels above the
> client area, but is makes no sense when it is below.
[Assuming above means outside and below means in]
What do you mean? Huw's suggestion makes perfect sense.
It just a little hard to implement. See below.
> 2. Whose responsibility it is to recognize this non-client
> area writing?
> Is it x11drv, GDI32 or USER32 ?
> I guess that x11drv since it is the part that knows what managed
> and unmanaged is, right?
As far as the USER32 is concerned the non-client area is just
another drawing area so from some point of view it should,
as you say, be handled in the x11drv.
However, perhaps (I'm not sure) USER32 should detect whether it draws
in the client area or not and pass on this information the underlying
driver somehow since there might be more drivers (MacOS X?) in the
future that will have the same problem.
Besides doing it only in the X11DRV forces doing some tricks it in the
GDI part of it, which probably is not that good.
> 3. How to detect this kind of non-client area writing in a clean way?
> Is there a call to do this?
> I guess this one I'd have to dig out of the code and the X11 docs.
The problems in that the application is not really writting in the
non-client area it is writting in the window area which consist of
the client area and the non-client area.
There is nothing preventing the application from writting in both
the client and the non-client area with the same GDI32 API call.
The more I think about it the more I'm inclined to believe that
Huw's suggestion concerning a special DC for DCX_WINDOW is the
only way to handle this in a reasonable way.
Implementing this will not be easy however. OK it will not be
that hard but it will take a lot of time, especially if
we are to implement support for drawing in both client and
non-client with one GDI32 call. However that can wait,
most applications will probably work with a simple one
or the other "multiplexing".
Of course the problem of actually drawing in the X Window
frame remains but that is a completely orthogonal problem,
that I can't help you with.
