🐛 IntelliSense tooltip never displayed in out-of-screen-bounds scenario - does not reappear when moving window back and changing the formula

[wh1t3cAt1k]

Setup: master ExcelDna.IntelliSense (as of 2021-03-09)

Our original issue was that customers were complaining that sometimes (especially during Zoom screen demonstrations!) IntelliSense tooltips would stop working - no tooltip was being displayed at all.

Manifests like that:

We were observing this issue sporadically but were never able to catch it.

I decided to give it a bit more attention now and I could reproduce a suspiciously similar problem when part of the formula was out of the screen bounds. After that - no arguments highlighting, no argument description, nothing!

Does not help if one moves the cell back into screen or changes the formula value. Only clearing the formula and re-typing it again helps.

See the below video for the demonstration - after moving the cell out of screen, I used my keyboard to start typing the formula. Note how the formula selection window does appear, but the tooltip never does.

intellisense-stopped-working.mp4

What could be at play here?

[govert]

It looks like some of the position tracking is not recovering once you move the window back into the desktop.

Some place like this would be a starting point:

IntelliSense/Source/ExcelDna.IntelliSense/UIMonitor/FormulaEditWatcher.cs

Line 352 in 3ebb765

EditWindowBounds = Win32Helper.GetWindowBounds(hwnd);

It tends to be impossible to debug this kind of thing, due to the focus interactions. But you can try to switch on Verbose logging, and then wade through the thick logs to get to the right place.

[wh1t3cAt1k]

Just got this under debug after repeating the same steps (moving the cell out of focus).

First I saw some suspicious messages in the Debug output:

^^^ FormulaEditStateChanged. CurrentPrefix: =, Thread 1
-#-#-#- Text Changed ...
GetClassName failed on 656934(0x656934) - Error 1400
GetClassName failed on 1377802(0x1377802) - Error 1400
GetClassName failed on 1443338(0x1443338) - Error 1400

Then, moving Excel window back into focus fully and typing the fomula again suddenly got this:

[wh1t3cAt1k]

Actually this exception seems to happen all the time with various class names.

Not sure if it's related to the original issue of the tooltip not showing.

[wh1t3cAt1k]

@govert (the issue with the _buffer seems to stem from the fact that it is a static variable and StringBuilder is not thread-safe - could it be a concurrent access problem with GetClassName?)

I can confirm that making it a local variable helps with the exception (admittedly at an expense of a more loaded GC), but native GetClassName call still fails all the time when moving Excel window around (Error 1400).

Making _buffer a local variable did not help with the issue of tooltip not being shown.

[wh1t3cAt1k]

In the original repro steps, when I bring the cell back into the visible area of the screen, I see ToolTipForm.MoveToolTip() handler triggering - and Visible == true at that point of time , but the tooltip is nowhere to be seen!

(maybe it went mad after having been drawn outside of the screen area?)

STATE UPDATE (FormulaEditMove): 
			FormulaEdit
	FormulaEditWindow: 2557510
	FormulaPrefix: =ACCOUNTBEGINNINGBALANCE(
	EditWindowBounds: 54,520,408,38
	ExcelToolTipWindow: 0 
IntelliSenseDisplay - FormulaEditMove
@@@ MoveToolTip - Old TopOffset: 0, New TopOffset: 0

When I clear the opening bracket symbol ( and re-enter it again, I see exactly the same logs (with the same window bounds), but this time, the tooltip is actually visible.

I tried replacing Invalidate() in MoveToolTip handler with Hide() + ShowToolTip(), nothing changed.

I also see quite a few errors like that in the logs: -#-#-#- Unexpected WindowsChanged object id: Self

[wh1t3cAt1k]

@govert the issue seems to reproduce with easier steps, too:

1. Enter the formula in cell A1 like =MYFORMULA( with an opening bracket to force the tooltip to open.
2. Move Excel window boldly to the left so that the tooltip is well behind the screen boundaries (but part of Excel window remains visible).
3. Move Excel window back - observe that the tooltip has disappeared.

In MoveToolTip() handler, Visible == true and Invalidate() is called, but I can confirm that no repaint operation happens.

[wh1t3cAt1k]

Just confirmed that even calling Refresh() instead of Invalidate() seems not to initiate the paint handler anymore.

[govert]

The GetClassName error looks bad to me.
I made some changes last year to get the main GetClassName call to run from the main thread.
But your exception might be due top the Debug call at WinEvents.cs L:231.
You might want to change this line, or change the conditional compilation symbol - it's probably a bad idea to call GetClassName from here but printing the hWnd should be OK.

Otherwise I'm not surprised at the window tracking being a bit buggy. You'll probably find there is some expectation of the Window event sequence that I had that is just not true in this case.
It would be great to improve it if you find a plan :-)

[govert]

There a calculation somewhere that resizes the tooltip window, so that it doesn't fall off the screen on the right hand side if the description is long. Maybe you should check this - it might be doing something silly if the tooltip gets moved off the left side.

Something like TooltipForm.cs L:457

[wh1t3cAt1k]

@govert it definitely stops repainting forever (or rather, until the tooltip is destroyed and recreated, e.g. by removing and reentering the opening bracket () , just as soon as the left + width becomes negative in this scenario (my log added):

The last thing I see in the log while it still repaints is something like -1000 XXX 1010 YYY - when I move it further to the left it stops repainting even after I move the window back.

I noticed how Excel native tooltip behaves in this scenario: the minimum left position for it is always zero.

Maybe DNA tooltip should behave the same way?

[wh1t3cAt1k]

This seems to help

One: in ShowToolTip():

Two: in UpdateLocation() handler:

Result:

It's consistent with how Excel native tooltip behaves.

[wh1t3cAt1k]

@govert If you agree with this fix I can create a pull request.

[govert]

@wh1t3cAt1k Thank you for tracking this down.
I was fiddling with the project, so I put your changes in too. Feel free to reopen the issue or add a new one if there are more of these niggles.