C# reparenting - focus problem

[jan.loucka]

Hi,
I looked around for this specific problem but could not find any
answer - there's few things in VB but still nothing exactly like this
so I'd appreciate any help.
We're writing C# WinForm application that need to "silently" use
another app (called MapInfo) within itself - the intention is to use
this app (which is quite sophisticated mapping application) and add
some other extra functionality to it. We have a dll so we can run the
application using InteropServices.
We created a main form that is MDI container and has multiple other
forms as children. One of these children is MapInfo form which has got
nothing in itself. It only creates MapInfo executable which is again
another MDI container (C# just doesn't know about it obviously -
MapInfo is written in C++). Inside this MapInfo form we're using this
WIN API methods (after the MapInfo object has been created and we have
a pointer to it):

SetParent(MapInfo handle, parentForm handle);
SetWindowLong(miWin, GWL_STYLE, WS_VISIBLE) - to get rid of the border
etc.

I have certain simple mechanisms how to communicate with this object
but I'm facing one problem. Since my Main parent form is MDI container
- when I click on any child of this form (not the MapInfo ones) the
main parent form keeps focus (I have a menu, toolbar etc there).
However when I click on the MapInfo form (the one that encapsulates
the Interop object in itself) the main Form looses focus. As a result
of that - when the user does something in MapInfo application and
decides to click on one of our controls (toolbar or menu in the main
MDI container form) then he has to click twice. Ones to get the focus
back to the main form. And second time to actually activate the
control. The problem is that when users are within MapInfo - they're
within MapInfo form (the fake empty one that we've written in C#) but
the MapInfo form never gets focus.
I'm open to any ideas hot to solve this problem - I'm sure there must
be some solution to this problem
Thanks
Jan

[Mr. Arnold]

<ja********@gmail.comwrote in message
news:11**********************@i13g2000prf.googlegr oups.com...

Hi,
I looked around for this specific problem but could not find any
answer - there's few things in VB but still nothing exactly like this
so I'd appreciate any help.
We're writing C# WinForm application that need to "silently" use
another app (called MapInfo) within itself - the intention is to use
this app (which is quite sophisticated mapping application) and add
some other extra functionality to it. We have a dll so we can run the
application using InteropServices.
We created a main form that is MDI container and has multiple other
forms as children. One of these children is MapInfo form which has got
nothing in itself. It only creates MapInfo executable which is again
another MDI container (C# just doesn't know about it obviously -
MapInfo is written in C++). Inside this MapInfo form we're using this
WIN API methods (after the MapInfo object has been created and we have
a pointer to it):

SetParent(MapInfo handle, parentForm handle);
SetWindowLong(miWin, GWL_STYLE, WS_VISIBLE) - to get rid of the border
etc.

I have certain simple mechanisms how to communicate with this object
but I'm facing one problem. Since my Main parent form is MDI container
- when I click on any child of this form (not the MapInfo ones) the
main parent form keeps focus (I have a menu, toolbar etc there).
However when I click on the MapInfo form (the one that encapsulates
the Interop object in itself) the main Form looses focus. As a result
of that - when the user does something in MapInfo application and
decides to click on one of our controls (toolbar or menu in the main
MDI container form) then he has to click twice. Ones to get the focus
back to the main form. And second time to actually activate the
control. The problem is that when users are within MapInfo - they're
within MapInfo form (the fake empty one that we've written in C#) but
the MapInfo form never gets focus.
I'm open to any ideas hot to solve this problem - I'm sure there must
be some solution to this problem
Thanks
Jan

Put a button on the form and make the button set form.control.focus to a
control on the main from?

[jan.loucka]

On Jun 13, 1:03 pm, "Mr. Arnold" <MR. [e-mail]:

<[e-mail] in message

news:11**********************@i13g2000prf.googlegr oups.com...

Hi,
I looked around for this specific problem but could not find any
answer - there's few things in VB but still nothing exactly like this
so I'd appreciate any help.
We're writing C# WinForm application that need to "silently" use
another app (called MapInfo) within itself - the intention is to use
this app (which is quite sophisticated mapping application) and add
some other extra functionality to it. We have a dll so we can run the
application using InteropServices.
We created a main form that is MDI container and has multiple other
forms as children. One of these children is MapInfo form which has got
nothing in itself. It only creates MapInfo executable which is again
another MDI container (C# just doesn't know about it obviously -
MapInfo is written in C++). Inside this MapInfo form we're using this
WIN API methods (after the MapInfo object has been created and we have
a pointer to it):

SetParent(MapInfo handle, parentForm handle);
SetWindowLong(miWin, GWL_STYLE, WS_VISIBLE) - to get rid of the border
etc.

I have certain simple mechanisms how to communicate with this object
but I'm facing one problem. Since my Main parent form is MDI container
- when I click on any child of this form (not the MapInfo ones) the
main parent form keeps focus (I have a menu, toolbar etc there).
However when I click on the MapInfo form (the one that encapsulates
the Interop object in itself) the main Form looses focus. As a result
of that - when the user does something in MapInfo application and
decides to click on one of our controls (toolbar or menu in the main
MDI container form) then he has to click twice. Ones to get the focus
back to the main form. And second time to actually activate the
control. The problem is that when users are within MapInfo - they're
within MapInfo form (the fake empty one that we've written in C#) but
the MapInfo form never gets focus.
I'm open to any ideas hot to solve this problem - I'm sure there must
be some solution to this problem
Thanks
Jan

Put a button on the form and make the button set form.control.focus to a
control on the main from?

But I don't want the users to click on a button - I'm trying to get
standard MDI behaviour. When child (in my case the MapInfo application
is activated) - even the parent should be focused. By the way - I
tried it and even when I try to set focus to the top form - it return
false. That means that it couldn't get the focus.

[Mehdi]

On Wed, 13 Jun 2007 02:30:52 -0000, ja********@gmail.com wrote:

As a result
of that - when the user does something in MapInfo application and
decides to click on one of our controls (toolbar or menu in the main
MDI container form) then he has to click twice. Ones to get the focus
back to the main form. And second time to actually activate the
control. The problem is that when users are within MapInfo - they're
within MapInfo form (the fake empty one that we've written in C#) but
the MapInfo form never gets focus.
I'm open to any ideas hot to solve this problem - I'm sure there must
be some solution to this problem

I did play with the idea of embedding external forms within a .NET
application form a long time ago but quickly gave up on that as it was
obviously not something that was ever meant to work well. I did encounter
similar focus problems. One thing that you could try is track the mouse
movement (either by using some of the MouseXXX events of your form or
overriding the WndProc method and intercept the Windows Messages there) and
attempt to set the focus back to your own form whenever you detect that the
mouse has left the area covered by the MapInfo form. It might or might not
work. Even if it works, it's definitely going one ugly hack that might
confuse the user but then your whole application seems to be one ugly hack
to start with so I guess that you won't be too bothered by that.