No TopMost will not do. The form cannot be TopMost.
It's a hidden menu form and when he user presses Windows+I the menu form
must show and come to the foreground (steal the foreground) without
being topmost.
Any other idea?
Kind regards
M O J O
rowe_newsgroups skrev:
On Nov 13, 10:58 am, M O J O <m...@nospam.no spamwrote:
>Hi,
>>
>How can I force a form to the foreground no matter what application is
>in front?
>>
>Thanks!
>>
>M O J O
Like the Outlook reminder window ... it steals the foreground without
being topmost.
????
Thanks!
M O J O
M O J O skrev:
Hi Seth,
>
No TopMost will not do. The form cannot be TopMost.
>
It's a hidden menu form and when he user presses Windows+I the menu form
must show and come to the foreground (steal the foreground) without
being topmost.
>
Any other idea?
>
Kind regards
M O J O
>
rowe_newsgroups skrev:
>On Nov 13, 10:58 am, M O J O <m...@nospam.no spamwrote:
>>Hi,
>>>
>>How can I force a form to the foreground no matter what application is
>>in front?
>>>
>>Thanks!
>>>
>>M O J O
On Nov 13, 9:39 am, M O J O <m...@nospam.no spamwrote:
Like the Outlook reminder window ... it steals the foreground without
being topmost.
>
????
>
Thanks!
M O J O
>
M O J O skrev:
>
>
>
Hi Seth,
>
No TopMost will not do. The form cannot be TopMost.
>
It's a hidden menu form and when he user presses Windows+I the menu form
must show and come to the foreground (steal the foreground) without
being topmost.
>
Any other idea?
>
Kind regards
M O J O
>
rowe_newsgroups skrev:
On Nov 13, 10:58 am, M O J O <m...@nospam.no spamwrote:
>Hi,
>
>How can I force a form to the foreground no matter what application is
>in front?
>
>Thanks!
>
>M O J O
>
TopMost = True
>
Thanks,
>
Seth Rowe- Hide quoted text -
>
- Show quoted text -
So, your trying to force a window to steal focus... Well, in the old
days you used to do that by calling SetForegroundWi ndow - the problem
is that this won't always work anymore. Microsoft "fixed" this
function in Windows98 timeframe to prevent exactly what your trying to
do - steal the focus...
Fortunately, there is a way around it. But, it involves a little more
work - you have to couple the call with a call to AttachThreadInp ut.
All-in-all your looking at several api calls. Here is an example in
classic VB, by the great Karl Peterson:
"Attempted to read or write protected memory. This is often an
indication that other memory has been corrupted."
Any idea?
Thanks!
M O J O
Tom Shelton skrev:
On Nov 13, 9:39 am, M O J O <m...@nospam.no spamwrote:
>Like the Outlook reminder window ... it steals the foreground without
>being topmost.
>>
>????
>>
>Thanks!
>M O J O
>>
>M O J O skrev:
>>
>>
>>
>>Hi Seth,
>>No TopMost will not do. The form cannot be TopMost.
>>It's a hidden menu form and when he user presses Windows+I the menu form
>>must show and come to the foreground (steal the foreground) without
>>being topmost.
>>Any other idea?
>>Kind regards
>>M O J O
>>rowe_newsgrou ps skrev:
>>>On Nov 13, 10:58 am, M O J O <m...@nospam.no spamwrote:
>>>>Hi,
>>>>How can I force a form to the foreground no matter what application is
>>>>in front?
>>>>Thanks!
>>>>M O J O
>>>TopMost = True
>>>Thanks,
>>>Seth Rowe- Hide quoted text -
>- Show quoted text -
>
So, your trying to force a window to steal focus... Well, in the old
days you used to do that by calling SetForegroundWi ndow - the problem
is that this won't always work anymore. Microsoft "fixed" this
function in Windows98 timeframe to prevent exactly what your trying to
do - steal the focus...
>
Fortunately, there is a way around it. But, it involves a little more
work - you have to couple the call with a call to AttachThreadInp ut.
All-in-all your looking at several api calls. Here is an example in
classic VB, by the great Karl Peterson:
>
I didn't download the code, but judging by the timestamp it was last
updated while VB.NET was still pre-release. One thing you might need
to do is update the API calls to the .Net equivalents, and for that
you should see www.pinvoke.net
After the conversion, let us know if the error disappears.
On Nov 13, 11:45 am, rowe_newsgroups <rowe_em...@yah oo.comwrote:
It is already VB. :o)
>
It may be VB, but it isn't VB.Net :-)
>
I didn't download the code, but judging by the timestamp it was last
updated while VB.NET was still pre-release. One thing you might need
to do is update the API calls to the .Net equivalents, and for that
you should seewww.pinvoke. net
>
After the conversion, let us know if the error disappears.
>
Thanks,
>
Seth Rowe
Seth, you are correct - it's VB Classic. I'm fairly sure, that I
indicated that in my post :) If not, I apologize to the OP.
Yes, jsut as Tom stated, calling AttachThreadInp ut with SetForegroundWi ndow
will definitely bring your window to foreground. But this is not a
recommended design on Windows, normally, you should just call
SetForegroundWi ndow. If the Windows finds that the end user is busy doing
operations, it will flash your window with blue colors in the taskbar. This
is a more recommended behavior than using AttachThreadInp ut.
Furthermore, SetForegroundWi ndow Win32 API is encapsulated in the .Net
Framework Form.Activate() method.
Public Sub Activate()
IntSecurity.Mod ifyFocus.Demand
If (MyBase.Visible AndAlso MyBase.IsHandle Created) Then
If Me.IsMdiChild Then
Me.MdiParentInt ernal.MdiClient .SendMessage(&H 222,
MyBase.Handle, 0)
Else
UnsafeNativeMet hods.SetForegro undWindow(New HandleRef(Me,
MyBase.Handle))
End If
End If
End Sub
So you may call me.Activate() to bring the form to the foreground.
Hope this helps.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.
On Nov 13, 8:16 pm, je...@online.mi crosoft.com ("Jeffrey Tan[MSFT]")
wrote:
Hi MOJO,
>
Yes, jsut as Tom stated, calling AttachThreadInp ut with SetForegroundWi ndow
will definitely bring your window to foreground. But this is not a
recommended design on Windows, normally, you should just call
SetForegroundWi ndow. If the Windows finds that the end user is busy doing
operations, it will flash your window with blue colors in the taskbar. This
is a more recommended behavior than using AttachThreadInp ut.
>
Furthermore, SetForegroundWi ndow Win32 API is encapsulated in the .Net
Framework Form.Activate() method.
Public Sub Activate()
IntSecurity.Mod ifyFocus.Demand
If (MyBase.Visible AndAlso MyBase.IsHandle Created) Then
If Me.IsMdiChild Then
Me.MdiParentInt ernal.MdiClient .SendMessage(&H 222,
MyBase.Handle, 0)
Else
UnsafeNativeMet hods.SetForegro undWindow(New HandleRef(Me,
MyBase.Handle))
End If
End If
End Sub
>
So you may call me.Activate() to bring the form to the foreground.
>
Hmmm... Learns something new each day. I know it's not
"recommende d", but there times when it makes sense - like the Outlook
notification type windows as the OP mentioned. So, could you call
AttachThreadInp ut and then call Form.Activate? I might have to try
taht :)
Yes, if you really have such requirement, you may p/invoke
AttachThreadInp ut and then call Form.Activate.
Additionally, I am not sure if Outlook calls AttachThreadInp ut internally,
but I do not think so. Because while I am performing daily works, the
Outlook Reminder or New Item Alert dialogs will just flash in the task. It
seems that they will not jump to the foreground rudely. Anyway, this is my
usage experience of Outlook :-).
Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.
Do you both make anti spam software to sell as everybody is setting there
spam on top of all other applications and make with that using the computer
impossible.
On Nov 13, 10:40 pm, je...@online.mi crosoft.com ("Jeffrey Tan[MSFT]")
wrote:
Hi Tom,
>
Yes, if you really have such requirement, you may p/invoke
AttachThreadInp ut and then call Form.Activate.
>
Additionally, I am not sure if Outlook calls AttachThreadInp ut internally,
but I do not think so. Because while I am performing daily works, the
Outlook Reminder or New Item Alert dialogs will just flash in the task. It
seems that they will not jump to the foreground rudely. Anyway, this is my
usage experience of Outlook :-).
>
Thanks.
Your probably right thinking about it... When an outlook popup
occurs, it does show up on top, and then fades out if ignored - but it
doesn't steal the focus.
I'm not talking about the Outlook new message popup - I'm talking about
the reminder popup. On my PC the reminder popup steals focus.
:o)
M O J O
Tom Shelton skrev:
On Nov 13, 10:40 pm, je...@online.mi crosoft.com ("Jeffrey Tan[MSFT]")
wrote:
>Hi Tom,
>>
>Yes, if you really have such requirement, you may p/invoke
>AttachThreadIn put and then call Form.Activate.
>>
>Additionally , I am not sure if Outlook calls AttachThreadInp ut internally,
>but I do not think so. Because while I am performing daily works, the
>Outlook Reminder or New Item Alert dialogs will just flash in the task. It
>seems that they will not jump to the foreground rudely. Anyway, this is my
>usage experience of Outlook :-).
>>
>Thanks.
>
Your probably right thinking about it... When an outlook popup
occurs, it does show up on top, and then fades out if ignored - but it
doesn't steal the focus.
>
--
Tom Shelton
>
Comment