Tooltip owns my VB form and my form dies when the tooltip 'fades'

[getitdone]

A similar issue occurred for ActiveX controls running under IE7, but I
couldn't find a resolution to it nor any reference outside of IE7. Dave
Massy, the IE project manager was involved in the IE issue.

In my case, I created an ActiveX DLL that uses a form for its user
interface. It works well, unless you have XP | Control Panel | Display |
Appearance | Effects... | Use the following transition effect for menus and
tooltips..." checked and set to "Fade effect". In that case, the form in my
DLL disappears as soon as the tooltip on the client application fades away.
The IE team said that the problem is that the tooltip becomes the 'owner' of
the form. This is confirmed by the fact that before my DLL 'crashed' (when
its StartUpPosition was set to CenterOwner), it would occasionally (when the
tooltip was visible) appear near the top of the client window where the
tooltip was located, instead of in the expected center of the client window.
A suggested fix was to avoid tooltips, but unfortunately, I am not the author
of the client applications and its hard to get them to stop using tooltips.
Here is what someone from the IE team wrote in the IE forum (Oct 2006):
____

A further update here. We have identified the issue and it is one that is
already being worked on. The issues is that the tooltip becomes the root of
the new window and when the tooltip goes away the entire thing falls apart.

There is a fix in the works but it is obviously too late for IE7 and will
also not make the final release of Vista. The VB team is currently working
through how to deliver the fix as soon as they can.

In the meantime the best advice we can give is to avoid tooltips. I’m
following up with the VB team to find out if there is any other solution that
would work until the fix is available.

I’m giving you these details almost as they happen so I can’t guarantee the
accuracy of any of the above as some things might change as investigation
continues

_____

There is nothing further in that thread from Microsoft. The thread is:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=686657&SiteID=1

and this information is near the bottom.

So here is my question: Is there any way for me to fix this problem from
within my ActiveX DLL?

Thanks,

John

[Ken Halter]

Post by getitdone
So here is my question: Is there any way for me to fix this problem from
within my ActiveX DLL?
Thanks,
John

Well, sadly, I wouldn't hold my breath waiting for "The VB team" to do
anything for any VB6 related issues. btw, If this is a dotNet question, note
there are dotNet groups and any solution you'd find here would be for
VB5/6...

But... can you reproduce this at will? What happens (or happened) when you
set the start position to anything except "CenterOwner". If this is a
specific app, you can always use a start position of Manual, find that app
using APIs and center your display using code. Since the tooltips surely
won't have the same window classes/titles/etc as the client app's main
window, you should be fairly safe from poorly positioned forms.

Since I can't begin to reproduce this, I don't know the chain of events that
are causing the problem... but, in your form's QueryUnload event, try
placing a msgbox there that tells you its UnloadMode. It's possible that you
can set Cancel = True and stop the form from unloading... based on
flags/variables/whatever you'd like.

[getitdone]

Hi Ken,

Unfortunately, it's not just the position of my form I'm worried about. At
some point my DLL has to do some work, and part of that work is polling a
hardware device. I can see from the lack of such polling (the device has a
'busy' light that should blink when it's polled) that my DLL has croaked, in
addition to its form disappearing from the screen. The 'CenterOwner' deal
was just what gave me the hint that something was going wrong even before my
DLL started doing anything. If I set the StartUpPosition to CenterScreen, my
form always appears in the center of the screen - until it disappears.

I tried putting a MsgBox in QueryUnload and I never saw it come up. It
looks like its not unloading the form, but somehow locking up before it can
do anything. The strange thing is that even though it seems to go nuts, I
don't get a GP fault or blue-screen. I just get the focus suddenly shifted
to some other application, and my client's application locks up as if my
ActiveX still had the focus.

I just heard from a client whose Tooltip causes this problem. He's using
Visual C++ 2003 and a 'Toolbar' editor that's built into Visual Studio.
Visual Studio doesn't provide a way to shut off the 'fade effect' that's
causing this problem. I know at the lower level there's a flag TTS_NOFADE
that is supposed to disable the fade effect, but this is apparently not
available in VC++.

- John

Post by Ken Halter

Post by getitdone
So here is my question: Is there any way for me to fix this problem from
within my ActiveX DLL?
Thanks,
John

Well, sadly, I wouldn't hold my breath waiting for "The VB team" to do
anything for any VB6 related issues. btw, If this is a dotNet question, note
there are dotNet groups and any solution you'd find here would be for
VB5/6...
But... can you reproduce this at will? What happens (or happened) when you
set the start position to anything except "CenterOwner". If this is a
specific app, you can always use a start position of Manual, find that app
using APIs and center your display using code. Since the tooltips surely
won't have the same window classes/titles/etc as the client app's main
window, you should be fairly safe from poorly positioned forms.
Since I can't begin to reproduce this, I don't know the chain of events that
are causing the problem... but, in your form's QueryUnload event, try
placing a msgbox there that tells you its UnloadMode. It's possible that you
can set Cancel = True and stop the form from unloading... based on
flags/variables/whatever you'd like.
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

[Ken Halter]

Post by getitdone
Hi Ken,
Unfortunately, it's not just the position of my form I'm worried about. At
some point my DLL has to do some work, and part of that work is polling a
hardware device. I can see from the lack of such polling (the device has a
'busy' light that should blink when it's polled) that my DLL has croaked, in
addition to its form disappearing from the screen. The 'CenterOwner' deal
was just what gave me the hint that something was going wrong even before my
DLL started doing anything. If I set the StartUpPosition to CenterScreen, my
form always appears in the center of the screen - until it disappears.
I tried putting a MsgBox in QueryUnload and I never saw it come up. It
looks like its not unloading the form, but somehow locking up before it can
do anything. The strange thing is that even though it seems to go nuts, I
don't get a GP fault or blue-screen. I just get the focus suddenly shifted
to some other application, and my client's application locks up as if my
ActiveX still had the focus.
I just heard from a client whose Tooltip causes this problem. He's using
Visual C++ 2003 and a 'Toolbar' editor that's built into Visual Studio.
Visual Studio doesn't provide a way to shut off the 'fade effect' that's
causing this problem. I know at the lower level there's a flag TTS_NOFADE
that is supposed to disable the fade effect, but this is apparently not
available in VC++.
- John

He's blowing smoke at you. This VB6 sample has an example of using that
flag.

CreateWindowEx: 21st Century ToolTips for VB - The Basics
http://vbnet.mvps.org/code/comctl/tooltip_basics.htm

But, since I can't reproduce the problem, no matter what I try, the only
thing I can suggest is (assuming it's not a modal form that's causing the
problem) place a timer on the form, at form_load get the form's parent
window. Every time the timer ticks make sure that value hasn't changed. If
it has, use SetParent to reparent the window back to its original owner.
That may seem like a lot of overhead, but it shouldn't be. Just an api call
or two per tick.

If it's only Modal forms that cause the greif, there are ways to get rid of
the modality and still have similar functionality... but, this is all "just
a theory" because I can't reproduce the problem.

[getitdone]

I found that code (in the link) and ran it on my XP system with the 'fading'
option enabled in control panel. I was trying to reproduce the problem, but
I too was unable to do so. Although I could see that setting 'Fade effect'
in Control Panel affected the way some other applications (IE7) displayed
their tooltips, the tooltips created using that sample application did not
fade, even if they didn't set the TTS_NOFADE flag.

The problem with my client is that he's using VC++ and the tooltip that is
causing the problem is associated with a 'toolbar' control. He can set the
tooltip text that appears over each command button in the toolbar, but that's
all he can do - short of implementing the toolbar and its tooltips himself -
which he's unwilling to do.

The form in question is modal. If I try to put a non-modal form in there, I
get an error.

- John

Post by Ken Halter

Post by getitdone
Hi Ken,
Unfortunately, it's not just the position of my form I'm worried about. At
some point my DLL has to do some work, and part of that work is polling a
hardware device. I can see from the lack of such polling (the device has a
'busy' light that should blink when it's polled) that my DLL has croaked, in
addition to its form disappearing from the screen. The 'CenterOwner' deal
was just what gave me the hint that something was going wrong even before my
DLL started doing anything. If I set the StartUpPosition to CenterScreen, my
form always appears in the center of the screen - until it disappears.
I tried putting a MsgBox in QueryUnload and I never saw it come up. It
looks like its not unloading the form, but somehow locking up before it can
do anything. The strange thing is that even though it seems to go nuts, I
don't get a GP fault or blue-screen. I just get the focus suddenly shifted
to some other application, and my client's application locks up as if my
ActiveX still had the focus.
I just heard from a client whose Tooltip causes this problem. He's using
Visual C++ 2003 and a 'Toolbar' editor that's built into Visual Studio.
Visual Studio doesn't provide a way to shut off the 'fade effect' that's
causing this problem. I know at the lower level there's a flag TTS_NOFADE
that is supposed to disable the fade effect, but this is apparently not
available in VC++.
- John

He's blowing smoke at you. This VB6 sample has an example of using that
flag.
CreateWindowEx: 21st Century ToolTips for VB - The Basics
http://vbnet.mvps.org/code/comctl/tooltip_basics.htm
But, since I can't reproduce the problem, no matter what I try, the only
thing I can suggest is (assuming it's not a modal form that's causing the
problem) place a timer on the form, at form_load get the form's parent
window. Every time the timer ticks make sure that value hasn't changed. If
it has, use SetParent to reparent the window back to its original owner.
That may seem like a lot of overhead, but it shouldn't be. Just an api call
or two per tick.
If it's only Modal forms that cause the greif, there are ways to get rid of
the modality and still have similar functionality... but, this is all "just
a theory" because I can't reproduce the problem.
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

[Ken Halter]

Post by getitdone
I found that code (in the link) and ran it on my XP system with the 'fading'
option enabled in control panel. I was trying to reproduce the problem, but
I too was unable to do so. Although I could see that setting 'Fade effect'
in Control Panel affected the way some other applications (IE7) displayed
their tooltips, the tooltips created using that sample application did not
fade, even if they didn't set the TTS_NOFADE flag.
The problem with my client is that he's using VC++ and the tooltip that is
causing the problem is associated with a 'toolbar' control. He can set the
tooltip text that appears over each command button in the toolbar, but that's
all he can do - short of implementing the toolbar and its tooltips himself -
which he's unwilling to do.
The form in question is modal. If I try to put a non-modal form in there, I
get an error.
- John

If that error is the one described in this article....

PRB: Modeless Forms in VB ActiveX DLL's Don't Display in VC++ Clients
http://support.microsoft.com/kb/247791/en-us

....ignore their lame work around and use something like this instead...

Work Arounds for Modal Forms?
http://groups.google.com.my/group/microsoft.public.vb.general.discussion/msg/a028170fb3123951