LabVIEW
Get Mouse Cursor
Solved!
BowenM wrote:
The more I work with XControls the more disappointed in them I become. They're good in concept, but fairly limited and buggy.
They are very limited, and very buggy in my opinion. But I can't help feel that if I can put enough effort into it, then the work arounds I have to do can all be hidden away in the code that never needs to be seen, because of a well implemented API. Good software tools think about how the developer will use them, and does whatever difficult tasks it takes to make their life easier. Writing a difficult API just needs to happen once. Using a crappy API may mean never using it, or having to code work arounds every time it is used. I'm hoping by the end of this I'll have an awesome XControl I can be proud of that does things that I won't have to reimplement all the time.
That being said I still think this instance of XControl weirdness, is my fault some how.
Anyone know what a control VI is? Does that mean XControl? If so, then the help file clearly says this method doesn't work there. I have never created an XControl.
@Hooovahh wrote:
GRRRRAHHHH...turns out this invoke node doesn't work right when in an XControl...which was the goal of all of this. I need to do some more testing but it appears this function always returns a -2 when in an XControl. If I can make a simple example I'll make a new thread.
Edit: it must be something else I'm doing the simple test works.
Okay so I tracked it down. Turns out the invoke node Get Clicked Column Header always returns a -2 if the control is an indicator. It only will return the clicked header when used on controls. I think I can make this work, but I made my MCLB an indicator because I thought it would make other accidental user interactions minimal. So now I'll need to capture all the mouse downs, and key downs, and discard any value changes made by them, which I guess isn't all that terrible. But for argument sake I'd say this function should operate on indicators. It can be valuable (like now) to know that the user clicked on a header to a control, whose value they can't change.
Yeah thanks for all the help. By Control VIs, I believe the help means .CTL files. It's a VI that is a control VI with no block diagram.
Also I found yet another work around to make my life easier. There is a property node that is the color of the selected items in a MCLB. If you set that to the same color as all the other cells, then when the value chagnes, on a mouse click, there is no UI indication that anything has changed. Which is perfect for me because it's just like ignoring the value change.
A value in a MCLB is the numeric of the selected row. In my application I don't want a click on the MCLB to highlight a row (or the first cell). Also for the Edit Cell? event that takes place after an edit as tried to be applied. So again the user could edit a cells contents then hit enter, and it would fire that event, where my code would then revert it. Allowing the user to edit it in the first place would go against what I'm trying to do. For me the color of the selected row, and then the value change event setting the local variable back to -1 works fine.
