I am displaying some data in a tree control, and the data in some cells is much larger (multiple long lines of text) than fits in the cell. When the mouse is hovered over the cell, LabView automatically displays what looks like a tip strip with the data in it. The tip strip is larger than the cell, so it can display more of the data than appeared in the cell, but it is still not big enough for some of the data- some of the text is cut off. There is an additional problem if the cell is near the bottom or right hand side of the monitor - the edge of the screen may cut off the text because of the positioning of the tip strip.
Is there is a way to control the size and location of the tip strip so all the data in the cell can be displayed. If that is not possible, is there a way to turn off the tip strip. I could then display the full text using a normally hidden string control that would be made visible and populated with the cell text when the mouse hovers over the cell. I've tried setting the App.ShowFPTipStrips property false, but that does not work for the tree cell tip strips (perhaps they are not really tip strips).
I'm assuming there is no way to control the size of the tip strip or turn it off and that it's simply built into the control.
One thing you can do to prevent it from appearing is to place a transparent decoration or control over the relevant part of the tree, which would prevent it from receiving the mouse events. The downside is that it will prevent it from receiving the mouse events, which would require you to use mouse events for the pane to reimplement the functionality you want. It would also be tricky to line it up correctly to account for automatic resizing, font changes, etc.
Another option might be to use a .NET tree control, where the tip strip behavior might be better.
I tried a couple of different ways of handling this.
1) Use the tree's mouse move event. Open a VI displaying the contents of the cell that the mouse is over. The VI is opened under the cursor, so the tree stops receiving mouse move events when the VI opens. Close the VI when the mouse leaves its front panel. The position and size of the VI is based on the cell position relative to the display bounds and the size of the cell contents. There were issues with getting the behaviour that I wanted and with blocking other cells when the VI opened.
2) Use a shortcut menu to open a VI displaying the cell contents when the user requests it. This was easier to implement in a way that did not cause VIs to be opening when they weren't wanted. It's slightly more work for the user, but gives the desired cell information when needed, was easier to implement, and achieved acceptable popup behaviour more easily.