[...]
But beyond any of that, .NET doesn't provide a way to do this. You
have
to go into the guts of things to fake it.
Really it does, you just override WndProc. This is all managed code.
I guess that's in the eye of the beholder. I don't consider any
solution that involves overriding WndProc to be "managed" per se.
Yes, it doesn't require the use of "unsafe", but it's definitely
getting into the underlying native Windows API, rather than relying
on the .NET Framework. And, of course, there still remains the
question as to whether overriding WndProc would be sufficient for the
OP's needs.
The way I read it he wants to clicks sent to the modal form. This
doesn't
seem that big a deal, in fact MS provide specifically for this with
their
non-client mouse messages. Those messages are there for a reason.
I agree, unless he clarifies, we don't really know what he wants to
do. To me, though, it sounds as though he wants the user to interact
with his first form, but have results from that show up in his second
(modal) form. It's not sufficient to just get mouse input from
outside the client area; he needs to, at a minimum, translate that
input relative to the first form (if not actually handle the click in
the first form...it's not really clear).
And I also agree that we don't know for sure that he's violating any
UI standard. But what he's doing sure *sounds* a lot like why we
have the concept of modeless dialogs in the first place. I haven't
seen anything that would suggest there's any good reason to make the
second dialog modal.
Pete