Modal Window Mouse Capture Outside of Bounds?

[bern11]

If Form1 opens Form2 modally, how do I capture clicks on Form1 when
Form2 is open? I want to click on Form1 and read the mouse co-ordinates
into Form2. Since Form2 is open modally, Form1 mouse-events do not
fire. What events on Form2 fire?
I could open Form2 modelessly, then process from within Form1 mouse
events. Is there any other way?

[Peter Duniho]

On Sun, 06 May 2007 20:42:05 -0700, bern11 <be****@yahoo.comwrote:

If Form1 opens Form2 modally, how do I capture clicks on Form1 when
Form2 is open?

You can't. That's the definition of modal...user input to other windows
is disabled.

[...]
I could open Form2 modelessly, then process from within Form1 mouse
events. Is there any other way?

No. If you want Form1 to get user input while Form2 is open, Form2 cannot
be modal.

Pete

[Michael C]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Sun, 06 May 2007 20:42:05 -0700, bern11 <be****@yahoo.comwrote:

>If Form1 opens Form2 modally, how do I capture clicks on Form1 when
Form2 is open?

You can't. That's the definition of modal...user input to other windows
is disabled.

>[...]
I could open Form2 modelessly, then process from within Form1 mouse
events. Is there any other way?

No. If you want Form1 to get user input while Form2 is open, Form2 cannot
be modal.

It depends on what you're doing. The modal form might be a dropdown that you
want to have disappear when the use clicks outside. For this I just override
WndProc and trap the non client mouse clicks. I think they start with WM_NC.

>
Pete

[Peter Duniho]

On Sun, 06 May 2007 21:36:13 -0700, Michael C <no****@nospam.comwrote:

>No. If you want Form1 to get user input while Form2 is open, Form2
cannot be modal.

It depends on what you're doing. The modal form might be a dropdown that
you want to have disappear when the use clicks outside. For this I just
override WndProc and trap the non client mouse clicks. I think they start
with WM_NC.

Well, it's programming. There is always a way to do anything you want.
But it is frequently not worth the trouble, and this is especially true
when one is essentially wanting to violate the standard UI behavior.

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.

I'll also point out that your example is a lot simpler than what the OP
wants, since in your case it's still your "modal form" that is getting the
mouse clicks. To address the OP's goal, you'd have to get those clicks,
translate them for the underlying form, and post them to that form's
message queue.

Pete

[Michael C]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

Well, it's programming. There is always a way to do anything you want.
But it is frequently not worth the trouble, and this is especially true
when one is essentially wanting to violate the standard UI behavior.

It really depends on the specific situation. We don't know if the OP is
violating anything.

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'll also point out that your example is a lot simpler than what the OP
wants, since in your case it's still your "modal form" that is getting the
mouse clicks. To address the OP's goal, you'd have to get those clicks,
translate them for the underlying form, and post them to that form's
message queue.

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.

Michael

[Peter Duniho]

On Mon, 07 May 2007 17:10:42 -0700, Michael C <no****@nospam.comwrote:

[...]

>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

[Michael C]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

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.

That's true, although it is technically managed it does require greater
knowledge. It not terribly difficult though.

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.

It is possible he wants to violate windows standards but my point was it is
quite possible he doesn't. Quite often I read what seems like outrageous
ideas on here but when explained further they make sense. For example when
customising a toolbar in excel the customise box is modal but you can drag
toolbar buttons off toolbars. I think the OP needs to explain, although we
haven't heard from him in a while.

Michael

[Peter Duniho]

On Mon, 07 May 2007 18:24:06 -0700, Michael C <no****@nospam.comwrote:

[...]
It is possible he wants to violate windows standards but my point was it
is quite possible he doesn't. Quite often I read what seems like
outrageous
ideas on here but when explained further they make sense. For example
when customising a toolbar in excel the customise box is modal but you
can
drag toolbar buttons off toolbars.

Funny you should bring that up. :) I suppose that UI is so entrenched
that it's the de facto standard now. But it's always bugged me, because
of the "sort of modal, sort of modeless" nature of it. You are correct
that it's modal. You can't do anything except what the toolbar customize
UI allows you to do, until you close the dialog box. On the other hand,
I've always felt there is insufficient feedback to the user with respect
to the modal nature. In a lot of ways, it *looks* modeless, even though
it's modal.

If I had my way, I would have designed the UI so that rather than it being
completely modal but looking non-modal, it would actually be modeless,
while making it clear that when the customize dialog box is active, you
are editing your UI rather than the document. The document itself would
be greyed out, dimmed, or otherwise displayed as inactive, but you would
still be able to do things like adjust the program's window size, or even
exit the application.

I realize a lot of this is subjective, and plenty of people probably
disagree (for sure, the program manglers over in the Office group do, I'm
sure :) ). But hopefully the above provides some insight into how I feel
about modeless versus modal.

I think the OP needs to explain, although
we haven't heard from him in a while.

Yup. Seems like a common problem when answering questions around here. :)

Pete

[bern11]

Peter Duniho wrote:

On Mon, 07 May 2007 17:10:42 -0700, Michael C <no****@nospam.comwrote:

>[...]

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

I want the clicks sent to the modal form. If I can capture them, I can
get the mouse screen position from the Cursor.Position property. I'm
actually after the screen pixel color that the mouse clicks on. I have
it working modelessly through an event handler in Form1. It would be
nice to keep it all in Form2 though.

[bern11]

bern11 wrote:

Peter Duniho wrote:

>On Mon, 07 May 2007 17:10:42 -0700, Michael C <no****@nospam.comwrote:

>>[...]

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

I want the clicks sent to the modal form. If I can capture them, I can
get the mouse screen position from the Cursor.Position property. I'm
actually after the screen pixel color that the mouse clicks on. I have
it working modelessly through an event handler in Form1. It would be
nice to keep it all in Form2 though.

PS. I want to keep it modal because the second form is an editor on the
first form. I'm masking out the pixel(s) in an image displayed in the
first form when they are clicked on. It works pretty cool. When it is
modeless, I cannot prevent other editing windows from opening and all my
'mode' flags become useless.

[Michael C]

"bern11" <be****@yahoo.comwrote in message
news:R5******************************@comcast.com. ..

PS. I want to keep it modal because the second form is an editor on the
first form. I'm masking out the pixel(s) in an image displayed in the
first form when they are clicked on. It works pretty cool. When it is
modeless, I cannot prevent other editing windows from opening and all my
'mode' flags become useless.

If it's working the way you're doing it then I'd leave it like that. Better
to use managed code if possible.