Tooltips persist at breakpoints

[Wolfgang]

Hello NI,

debugging a program that uses tooltips may get complicated because the tooltips persist on the screen - they float above all other applications and thus it is impossible to get rid of them, this includes the IDE: it may happen that at a breakpoint the program stops but that the variable window or the source code is (partially) covered by the tooltip... since the tooltip cannot be moved it may render debugging impossible. This means that one has to take great care that no tooltip is shown during debugging...

I feel that this is undesirable behavior: at a breakpoint the tooltips should 'disappear', too.

[LuisG]

Hi Wolfgang,

I agree that this can be inconvenient, but there really isn't much that the debugger can do to avoid it. By definition, when you hit a breakpoint, everything suddenly stops in the program that is being debugged. Every single thread freezes. This means that any windows owned by the program, including the tooltip windows, can't be updated/redrawn, nor can they be destroyed.

One possible workaround for you is to use the Run>>Refresh User Interface command (Ctrl-R). This injects a short message pump in the debuggee that allows it to process system messages. If the debuggee can process these messages, even for a few milliseconds, it will most likely be able to not only redraw its windows (hence the name "Refresh User Interface") but also to destroy the tooltips, assuming the mouse is no longer over the tooltip at that point.

Keep in mind, however, that even something as seemingly inocuous as processing a few messages in the frozen program can sometimes have unexpected results: a callback might unxpectedly get called, or some other asynchronous task that you weren't expecting might also execute. So, don't be too surprised if your program does some weird things when you invoke this command.

Luis

[Wolfgang]

Hi Luis,

I haven't been surprised for a long time by my programs doing weird things 

Concerning CVI: once a breakpoint is hit, the z-order of the panels is changed; I don't know if the executable moves back showing the source code editor or if the IDE is moved to front. So I thought that it might be possible to change the z-panel order of the tooltips panel, too...

[LuisG]

The CVI ADE should come to the foreground whenever a breakpoint is hit. If you maintain your ADE maximized, then at this point you'd stop seeing your program's windows and you might not even notice that they've stopped refreshing (you'd have to move your ADE window out of the way to see them).

However, the tooltip windows are different. They are floating windows, and because of that they also float over other programs. This is why you are seeing your floating windows over the ADE, even though all your other program windows remain hidden behind the ADE (since I can't see what you see, there's some speculation in what I'm saying, but it makes sense to me, so I'll stick to it for now ).

Luis

[Wolfgang]

Thank you Luis for sharing your knowledge! It definitely makes sense

But before I give up on this subject: why do tooltips have to be set to VAL_FLOAT_ALWAYS - wouldn't it be sufficient if they would be set to VAL_FLOAT_APP_ACTIVE? They do not need to float above different applications, right? Actually I find it somewhat strange that they do... Changing this attribute would solve the debug issue, too.

What did I miss?

I am adding an example of this z-plane 'disorder' - I don't think that this tooltips behavior makes much sense...

[LuisG]

You raise a good point, but unfortunately VAL_FLOAT_APP_ACTIVE and VAL_FLOAT_ALWAYS is a distinction that only applies to CVI panels. It's not a general windowing concept, and so it doesn't really apply to tooltip windows, which are low level windows, not panels. As far as Windows is concerned, there is only floating and not-floating.

Panels implement the VAL_FLOAT_APP_ACTIVE by trapping the messages that are sent when the application comes to the foreground or leaves the foreground, and then disabling the floating attribute of the corresponding window. This can't be done for the tooltips of a program that is being suspended by a breakpoint since there is no way to execute this type of event handler when a program is suspended.

I didn't try this myself, but my guess is that if you suspend a program that has a floating panel, that panel will remain floating over the ADE regardless of whether its attribute is VAL_FLOAT_APP_ACTIVE or VAL_FLOAT_ALWAYS (at least I hope that is the case, otherwise I'm missing something). This is because when the application is suspended it doesn't have the chance to honor the VAL_FLOAT_APP_ACTIVE choice.

I agree that your screenshot looks odd, but that's for a different reason. From what I've seen, it's not common for tooltips to trigger unless their parent window is already in the foreground. Therefore, you normally wouldn't end up with a situation where you trigger a tooltip when the window is behind another window. I agree that CVI is unorthodox about this, and may be that the current behavior is debatable (I honestly don't know exactly how unique it is, since I only tried 2 or 3 other apps). But, in any case, it's a separate issue from what happens when you suspend your program or the distinction beween VAL_FLOAT_APP_ACTIVE and VAL_FLOAT_ALWAYS.

Luis

[Wolfgang]

Dear Luis,

Thank you very much for your detailed answer! I consider it quite useful to better understand issues even if they are not resolved...