bjustice

Ok, I've cross-posted to the NI forums: https://forums.ni.com/t5/LabVIEW/mouse-scroll-array-indicators-bug-LAVA-x-post/td-p/3730630 I linked the LAVA forum there as well. (Not sure of etiquette here) thanks!

Hello everyone! I've noticed a behavior in LabVIEW that has me a bit puzzled, and I wanted to know what you guys think. (See attachments) I'm currently working in LabVIEW 2017. As the image points out, I am able to use my mouse wheel to scroll control arrays. However, whenever I mouse-wheel over an array indicator.... the indicator goes to index=0. Is this intended behavior? Since I like to be able to mouse-wheel on arrays in GUIs, I am finding myself creating control arrays... setting to a disabled state... and then updating the controls via property node so that I can effectively have an indicator that has mouse-wheel scrolling capability. Thoughts? Thanks! mousescroll.vi

Smith, thank you for your answer and for linking these pages. I found them very helpful.

Tortoise SVN with command line tools installed. This lets me call SVN from the LabVIEW system exec, which I use for various applications

Hey guys! So, I've installed LabVIEW 2017 and I'm starting to play around with it. Malleable VIs are cool! (No more giant OpenG toolkits where there are 10 instances of the same VI for multiple datatypes.) Another cool thing that I've observed is that the example "sort 2D Array" function can support a scalar and an array input for index. Upon further digging, there appears to be an interesting disable structure that intelligently selects the upstream input that yields non-broken code. Does anyone have more information about this structure? Is this related to the experimental structure that Hooovah talked about in his Xnodes presentation at NI week? I'm just curious if this is stable... and if I can start using it... and it there is any documentation on it that would tell me how to use it.

Hi Hooovah! I suppose that I've lurked long enough; maybe I should post something. So, hello! I just got back from NI week --> this was my 2nd time attending. I bought you a beer at the LAVA BBQ. (That means I get Kudos, right? How does this internet thing work?) The advanced users track brought me back to the conference again this year. What a great group of people I have a degree in aerospace engineering with no formal software engineering education. I sorta taught myself LabVIEW in college for various projects. I've been working pretty heavily in LabVIEW during the last 4 years. I was at SpaceX for a bit, and now I'm at Blue Origin. I don't post very much simply because I don't have the time. Work keeps me busy, even when at a full sprint. When I jump on the forums, it usually because I've run into a limitation of LabVIEW, and am looking for a workaround. If I don't find an acceptable workaround in 20 minutes, I will usually move on with a different solution. I don't have the time to post a questions and collect further feedback or to contribute on a discussion. I wish that I could share more code with the community, but most of what I do is work related... and cannot be shared. Nonetheless, I do have one project from college that I've posted online. It's pretty old now, and I've come a long way since then, but maybe it's a project worth sharing in this thread. Enjoy!: Link Anyways, I'll try to post more and participate in discussions. You guys rock, cya at NI Week next year! -Brent

The only time I might be tempted to use 2 ES is when I want to split out UI events and control reference event registration. More specifically, when registering control references, you have to deal with the issue where you are not allowed to register when the FP is closed. (See related post here). I like to isolate this issue from affecting UI events and other dynamic event registrations. If this issue were fixed, I would have no objections. I'd have to revise some legacy code, but if there are major advantages to NI for doing this, I would understand.