Tooltip and non-modal window

[Entropy]

Ok, first, I want to apologize for the lack of code examples here, I am working on a private network and cannot move the code from there to here.

I have a help tooltip system we have written that is working great 99.9% of the time with the Ext.Tooltip. The tooltips show and hide pretty well MOST of the time. When they fail, they fail in preference of NOT showing, which is good.

Except one spot. We have a button that launches a non-modal extended Ext.Window. The button that launches it has tooltip. It shows the tip, click the button and that tip lingers since it never detected the mouseout. Okay, mild annoyance, but no big deal especially with the dismissDelay set.

Finish your work and clsoe the window, and when you mouseover the launching button (or any other button on the same toolbar) and it spawns the tip at 0,0 on the bwoser. These phantom tips refuse to close, time out, or go away programatically (I iterate through all my tips to hide() them as one of my attempts to solve the behavior).

Mouseing over ANY other button or link that launches a tooltip works fine except for this ONE toolbar that contains the button that spawned the window (and had a tip up when the window was launched). I am trying to find out if there is anything else different or special about it, but at this time, it does not appear so.

Does anyone have any ideas on how to correct this issue, or at least how to mitigate it, or even a line of inquiry for me to explore to solve it?

[arthurakay]

What version of Ext are you using? Do you use any UX classes? Do you apply any extra CSS to your tooltops?

If I had to guess, I would check the tooltips managed by the offending Toolbar to see if they share any common code. Maybe you have a local variable or object property shared between them that has been scoped incorrectly.

[Entropy]

First of all, thanks for responding so quickly!

What version of Ext are you using?

3.2.1

Do you use any UX classes?

Yes, though none are in play here. The tooltips are standard, the window shown is extended from Ext window (probably doesn't need to be extended, but many developers on my project are in the bad habit of extending when they don't need to), etc. And those ux classes that are in use elsewhere don't seem to interfere with any other tooltips. It seems most likely that the issue either has to be related to this toolbar, this button, the events they call, the window, or the events the window runs. But there's alot of stuff in there, and I was hoping someone else had this issue so as to narrow it down.

A list of ux in use throughout the app: XmltreeLoader, ItemSelector, FileUploadField, Image. The last three are not active on the page when this is happening. The first is in use, though not by any control near the problem.

Do you apply any extra CSS to your tooltops?

Great question. I hadn't even thought about that. Our tips use an achor and some text. I believe there are some external CSS's that modify those. Also, in the tooltip itself I have some local style attributes setting most text stuff like text-decoration:none, color, white-space: no-wrap, text-align: right on one portion, a font-size, and a width:100% on a div. Nothing there jumps out at me the way a position: setting might.

I would check the tooltips managed by the offending Toolbar to see if they share any common code.

Well, the thing is that ALL of our tips have identical code. Our tips are databased and pulled down to be populated into the tip. The tips are then searchable through another area of the app. So each button just calls a common function with it's id and the topic id it binds to, and the common routine creates a tip with the appropriate text inside.

Maybe you have a local variable or object property shared between them that has been scoped incorrectly.

Quite possible. This is one of the things I am looking into. I am trying to analyze the window code to see if maybe we are re-using an id or something like that. Unfortunately, it is largish, and that will take time, and there is significant chance of missing something.

[Entropy]

I should probably also mention that I did try replacing the offending window with just a generic test window with no content, and the issue does not happen. So there is something inside that window that causes the conflict. The window is a complicated one with alot of panels and controls and drag/drop zones and stuff.

[arthurakay]

It sounds like you have a good handle on how to debug the issue... I'm glad you're already narrowing it down.

Unfortunately, I don't know how much I or anyone on the forum can help without actually seeing some of your code. From what you describe, it doesn't sound like that's even possible given the large code-base you're working with.

Knowing that the issue is somehow related to this one Window extension, I would recommend temporarily remove bits of it to further narrow-down the problem.

Also, since you mentioned that you're using anchors for your ToolTips, I would check to make sure the anchor you're using for the ToolTips is what you are expecting. Reread the API docs on AnchorLayout to be sure you have thing configured correctly.

If you figure out the solution, let me know what you've found. You have made me very curious

[Entropy]

SOLVED

So here is the problem - deep in the window, as it closes, another developer triggered the toolbar the buttons are on to be rebuilt. Things can happen in the window that can change the state of the toolbar, and rather than synch them up, someone just recreated them since the creation method has the rules on what to show and when.

So the root cause here is Ctrl X has Tip Y. Ctrl X is destroyed, and recreated as X2, and the code to bind the tip is called, creating Y2. The old tip Y is still around and doesn't realize it is bound to a dead control. Presumably because their IDs are the same (or the id of the ctrl they are bound to), when I mouseover X2, Y and Y2 both display, but Y is confused about where to draw, and thus draws at 0,0. It seems to me that when X is destroyed, Y should go with it, but this did not appear to happen.

My solution/wprkaround was to rewrite my tooltip method to hunt down and destroy Y for me before binding Y2 to X2. I tried calling QuickTips.unregister (though I am just instantiating Tooltip object, so I am not sure that applies) and it did nothing. I instead called an explicit destroy on Y. This worked. Yay!

Thanks for your quick responses. Sorry about not being able to post the code, but the nature of this project makes it impossible. Which is frustrating.