TopMost problems

[E Goforth]

Hello,

I have a VB6 app that calls a VB.NET app via named pipes and a third
party component. Inside the VB.NET app I'm trying to force a form to
the top, at least temporarily. Inside a form's public sub I'm doing:

Public Sub ThisIsMySub(The seAreMyArgument s)
Me.Show
Me.WindowState = FormWindowState .Normal
Me.TopMost = True
Me.TopMost = False
End Sub

However, my form doesn't pop on top like I'd expect it to. BTW the form
is an MDIParent.

I wrote a simple proof-of-concept VB.NET application with a timer
control on an MDI Parent form. I do the same steps as above it works as
I'd expect. When the timer_tick event fires my MDIParent form pops on
top. I can then move another app on top of it or minimize my MDIParent
form. The next time the timer_tick event fires it pops back on top.

The only thing that I could figure out is that another form in my app
had it's TopMost property set to True. I have a StatusBar form that
does this, but I did some checking and its unloaded by the time I do my
"Me.TopMost = True
" Any idea what could be going on?

Thanks,
Eric
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tom Shelton]

In article <Oc************ **@TK2MSFTNGP10 .phx.gbl>, E Goforth wrote:

Hello,

I have a VB6 app that calls a VB.NET app via named pipes and a third
party component. Inside the VB.NET app I'm trying to force a form to
the top, at least temporarily. Inside a form's public sub I'm doing:

Public Sub ThisIsMySub(The seAreMyArgument s)
Me.Show
Me.WindowState = FormWindowState .Normal
Me.TopMost = True
Me.TopMost = False
End Sub

However, my form doesn't pop on top like I'd expect it to. BTW the form
is an MDIParent.

I wrote a simple proof-of-concept VB.NET application with a timer
control on an MDI Parent form. I do the same steps as above it works as
I'd expect. When the timer_tick event fires my MDIParent form pops on
top. I can then move another app on top of it or minimize my MDIParent
form. The next time the timer_tick event fires it pops back on top.

The only thing that I could figure out is that another form in my app
had it's TopMost property set to True. I have a StatusBar form that
does this, but I did some checking and its unloaded by the time I do my
"Me.TopMost = True
" Any idea what could be going on?

Thanks,
Eric
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Since windows 98 you can't force a window to the foreground if another
application window has focus. The only way, I know of to get around
this behavior on all os's is to use P/Invoke to find the threadid of the
current foreground window and then call AttachThreadInp ut to attach to
that threads input queue - you can then call SetForegroundWi ndow to move
your application to the front, andt then call AttachThreadInp ut again to
detach from the thread input queue...

I know it sounds complex, but it goes something like (air code):

Dim currentForegrou nd As IntPtr = GetForegroundWi ndow()

If currentForegrou nd = Me.Handle Then
SetForegroundWi ndow(Me.Handle)
Else
Dim processId As IntPtr
Dim threadId As IntPtr = GetWindowThread ProcessId( _
currentforegrou nd, processId)
Dim currenThread as IntPtr = GetCurrentThrea d()

AttachTheadInpu t(currentThread , threadId, True)
SetForegroundWi ndow(currentFor eground)
AttachThreadInp ut(currentThrea d, threadId, False)
End If

In Windows ME and above, you can call AllowSetForegro undWindow to give
the other process specific permission to steal focus - but it won't work
on windows 98, so I prefere the above method. I hope I haven't forgot
anythign :) I do have a working example of this - though it is in C#,
so if you can't get it working I can try and dig it out.

--
Tom Shelton
MVP [Visual Basic]

[Tom Shelton]

In article <uq************ **@TK2MSFTNGP11 .phx.gbl>, Tom Shelton wrote:

In article <Oc************ **@TK2MSFTNGP10 .phx.gbl>, E Goforth wrote:

Hello,

I have a VB6 app that calls a VB.NET app via named pipes and a third
party component. Inside the VB.NET app I'm trying to force a form to
the top, at least temporarily. Inside a form's public sub I'm doing:

Public Sub ThisIsMySub(The seAreMyArgument s)
Me.Show
Me.WindowState = FormWindowState .Normal
Me.TopMost = True
Me.TopMost = False
End Sub

However, my form doesn't pop on top like I'd expect it to. BTW the form
is an MDIParent.

I wrote a simple proof-of-concept VB.NET application with a timer
control on an MDI Parent form. I do the same steps as above it works as
I'd expect. When the timer_tick event fires my MDIParent form pops on
top. I can then move another app on top of it or minimize my MDIParent
form. The next time the timer_tick event fires it pops back on top.

The only thing that I could figure out is that another form in my app
had it's TopMost property set to True. I have a StatusBar form that
does this, but I did some checking and its unloaded by the time I do my
"Me.TopMost = True
" Any idea what could be going on?

Thanks,
Eric
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Since windows 98 you can't force a window to the foreground if another
application window has focus. The only way, I know of to get around

I should clarify, that it is a window of another process. If the window
is in your own process, then all is ok :)

<snip>

--
Tom Shelton
MVP [Visual Basic]

[E Goforth]

Hello,

I'm doing my development/testing on an XP box, which is what the users
will be running. Maybe some Win2k, but certainly no Win9x. If you
can't force a window to the foreground if another application window has
focus, how come my proof-of-concept app VB.NET app works so nicely. I
minimize my VB.NET form open up several applications and it pops on top
when the timer fires. I then shift focus back to my other apps or
minimize my VB.NET form and it pops back on top when the timer fires
again, ad infinitum

-Eric

Tom Shelton wrote:

In article <Oc************ **@TK2MSFTNGP10 .phx.gbl>, E Goforth wrote:

Hello,

I have a VB6 app that calls a VB.NET app via named pipes and a third
party component. Inside the VB.NET app I'm trying to force a form to
the top, at least temporarily. Inside a form's public sub I'm doing:

Public Sub ThisIsMySub(The seAreMyArgument s)
Me.Show
Me.WindowState = FormWindowState .Normal
Me.TopMost = True
Me.TopMost = False
End Sub

However, my form doesn't pop on top like I'd expect it to. BTW the form is an MDIParent.

I wrote a simple proof-of-concept VB.NET application with a timer
control on an MDI Parent form. I do the same steps as above it works as I'd expect. When the timer_tick event fires my MDIParent form pops on top. I can then move another app on top of it or minimize my MDIParent form. The next time the timer_tick event fires it pops back on top.

The only thing that I could figure out is that another form in my app
had it's TopMost property set to True. I have a StatusBar form that
does this, but I did some checking and its unloaded by the time I do my "Me.TopMost = True
" Any idea what could be going on?

Thanks,
Eric
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Since windows 98 you can't force a window to the foreground if another
application window has focus. The only way, I know of to get around

I should clarify, that it is a window of another process. If the window
is in your own process, then all is ok :)

<snip>

--
Tom Shelton
MVP [Visual Basic]
..


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tom Shelton]

In article <ee************ **@TK2MSFTNGP11 .phx.gbl>, E Goforth wrote:

Hello,

I'm doing my development/testing on an XP box, which is what the users
will be running. Maybe some Win2k, but certainly no Win9x. If you
can't force a window to the foreground if another application window has
focus, how come my proof-of-concept app VB.NET app works so nicely. I
minimize my VB.NET form open up several applications and it pops on top
when the timer fires. I then shift focus back to my other apps or
minimize my VB.NET form and it pops back on top when the timer fires
again, ad infinitum

-Eric

It seems I misread what your trying to do... I thought you were trying
to take the input focus. That is accomplished via the
SetForegroundWi ndow API and that does not work accross processes. What
you are describing is the SetWindowPos function - moving a window to the
top of the z-order. That does work, but it does not steal the input
focus - in other words, the window pops forward, but the window that
previously had focus still does...

Simple test, open notepad and start typing. Even after the window pops,
you will still be typing in notepad (this is the behavior that I get on
my XP box). The only way to gain input focus is to use the method I
described (or you can use the AllowSetForegro undWindow API since your
on 2K and XP)

Making a topmost window with setwindowpos (which is what is happing with
the TopMost property), is only valid until another window is made
topmost. I presume that there is another window that is stealing the
topmost position.

Is there any way you can post some code that recreates the problem? It
would be much easier to diagnose if there was a small example.

--
Tom Shelton
MVP [Visual Basic]

[E Goforth]

Hello,

Is there a good way to tell which window is getting stealing TopMost
away from my Window? I put some trace statements in my code and they
indicated that the only likely culprit I could think of was closed and
set to Nothing by the time that my form was set TopMost.

Is it possible that the Garbage Collector hasn't cleaned up the suspect
form by the time my form is set TopMost? Does TopMost care if there's
another TopMost form in the garbage?

Tom Shelton wrote:
-------------------------------------
In article <ee************ **@TK2MSFTNGP11 .phx.gbl>, E Goforth wrote:

Hello,

I'm doing my development/testing on an XP box, which is what the users
will be running. Maybe some Win2k, but certainly no Win9x. If you
can't force a window to the foreground if another application window has focus, how come my proof-of-concept app VB.NET app works so nicely. I
minimize my VB.NET form open up several applications and it pops on top when the timer fires. I then shift focus back to my other apps or
minimize my VB.NET form and it pops back on top when the timer fires
again, ad infinitum

-Eric

It seems I misread what your trying to do... I thought you were trying
to take the input focus. That is accomplished via the
SetForegroundWi ndow API and that does not work accross processes. What
you are describing is the SetWindowPos function - moving a window to the
top of the z-order. That does work, but it does not steal the input
focus - in other words, the window pops forward, but the window that
previously had focus still does...

Simple test, open notepad and start typing. Even after the window pops,
you will still be typing in notepad (this is the behavior that I get on
my XP box). The only way to gain input focus is to use the method I
described (or you can use the AllowSetForegro undWindow API since your
on 2K and XP)

Making a topmost window with setwindowpos (which is what is happing with
the TopMost property), is only valid until another window is made
topmost. I presume that there is another window that is stealing the
topmost position.

Is there any way you can post some code that recreates the problem? It
would be much easier to diagnose if there was a small example.

-------------------------------------
Eric Goforth
Raleigh, NC

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tom Shelton]

On 2003-10-15, E Goforth <an*******@devd ex.com> wrote:

Hello,

Is there a good way to tell which window is getting stealing TopMost
away from my Window? I put some trace statements in my code and they
indicated that the only likely culprit I could think of was closed and
set to Nothing by the time that my form was set TopMost.

Is it possible that the Garbage Collector hasn't cleaned up the suspect
form by the time my form is set TopMost? Does TopMost care if there's
another TopMost form in the garbage?

Well, you may try to call Dispose on the form when your done with it -
but I don't think that will solve the problem. If you set a new TopMost
window, then that should automatically invalidate any other window as
the topmost....

What you may try is to use the GetTopWindow function, do see which is
the topmost window...

Declare Function GetTopWindow Lib "user32.dll " (ByVal hWnd As IntPtr) As IntPtr

You can pass in your main forms handle, and it should return the handle
of the window at the top of the zorder... This may serve as a check
anyway...

HTH
--
Tom Shelton
MVP [Visual Basic]

[Fergus Cooney]

Hi E, Tom,

I may be wrong on this but it makes sense that FormX.Close calls
FormX.Dispose. And this should release all unmanaged resources immediately as
it knows that FormX has been finshed with. Then FormX can sit in the GCs pile
until Doomsday. My understanding is that the cleaning up that's done in
Finalize should be the just-in-case-they-didn't-call-Dispose type of stuff.

Regards,
Fergus

[Tom Shelton]

On 2003-10-16, Fergus Cooney <fi******@tesco .net> wrote:

Hi E, Tom,

I may be wrong on this but it makes sense that FormX.Close calls
FormX.Dispose. And this should release all unmanaged resources immediately as
it knows that FormX has been finshed with. Then FormX can sit in the GCs pile
until Doomsday. My understanding is that the cleaning up that's done in
Finalize should be the just-in-case-they-didn't-call-Dispose type of stuff.

Regards,
Fergus

You maybe right on the Close calling dispose... I'll have to check that
out. Either way, I don't think that's his problem. I think it is going
to boil down to his communication method myself, but just trying to
cover all the bases :)

--
Tom Shelton
MVP [Visual Basic]

[E Goforth]

Hello,

Do the AllowSetForegro undWindow and SetForegroundWi ndow APIs make the
window in the foreground permanently? I just want it to pop to the top
of the z-order, but then allow the user to put other windows on top, if
they want to.

Eric Goforth
Raleigh, NC

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!