I wrote a little Tip Strip package, which I'd like to share with the community. It allows you to register any number of front panel objects to show a custom tip strip on mouse over. I think it might be useful for people who make lots of tip strips for UI documentation and who need to check to make sure they've all been written, since the usual tip strip functionality is so slow. It's also nicer for the user who needs the information to appear faster or stay on screen longer than the default tip strip.
I think there are a number of useful techniques here, some of which I've just recently learned, so I would very much welcome feedback, and I hope others find this useful. Some things I learned from this exercise that I think are useful:
1. I learned how to make the tip strip VI follow the mouse by getting the mouse coordinates, resizing the VI to the tip strip indicator, resizing the indicator to the size of the tip strip text.
2. In order to disable the normal tip-strip functionality, I read a control's tip strip value and then overwrite this value with a blank string. If there is no tip strip text, the default tip strip behavior is subverted. Then I display my own tip strip. When done, the original tip-strip text is written back to the control.
3. I wasn't happy with the abrupt appearance and disappearance of the tip strip, so I wrote a fade-in/fade-out routine. This is run asynchronously, so that the other functionality, like the tip strip following the mouse, still works.
4. I used to do asynchronous calls by opening a VI reference by path, using a static path on the diagram. By using a Static VI Reference instead, a built executable will automatically include the VI without the need to explicitly include them in the build specifications. Now I feel better about including asynchronous calls to VIs.
5. I find it frustrating that it requires so much code to do an asynchronous call to a VI. I really wish it were possible to have this be a settable property of any VIs execution. As it is now I usually make a separate calling VI, which has the same controls and connector as the VI I want to call. Seems we could avoid this. Thoughts?
6. In doing an asynchronous call, I've used two approaches here. One is to set a VIs FP control values by named reference, and then use an invoke node to call and forget. The recommended way is to use the Asynchronous Call and Forget node, which has the advantage of using the wiring terminals of the called VI, but then you have to remember (or look up) the code (x80) to wire to the Open VI Reference VI. (Why aren't these few options enumerated for us in a constant??). There are examples of both here. I'd be interested to hear views on these two methods.
7. Registering for Events: Since the controls are not known by the calling VI at run time, you must register for events. I pass in an array of the controls I want to apply tip strips to, and these are registered for mouse in, mouse move, mouse out, and mouse click. This was my first use of registering for events. Great stuff!
8. Because the tip strip VI is run asynchronously, we ensure that it closes when the calling VI ends by passing in a notifier. We read this notifier in the event structure timeout case. It will return an error when the notifier is destroyed by the VI that created it.
_____________
Creator of the BundleMagic plugin for LabVIEW!
