Leaderboard

One thing I absolutely wish is that NI would have a publicly facing issue tracker. For example, the jira for jira: https://jira.atlassian.com/projects/JRASERVER/issues/JRASERVER-67872?filter=allopenissues or the bugzilla for mozilla: https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Firefox&content=crash&comments=0 I've heard the NI argument against older issues -- there may be internal or customer-specific information, but I don't see that as an excuse moving forward. Or, another way, make an idea exchange for bugs. If something hasn't been fixed in 8 years it means that people thought it was too hard to fix or that not enough people are effected or some other combination of factors -- being able to locate bugs and see the workaround or press a button to say "this affects me too!" would make their decisions significantly less noisy, it seems to me. Much of marketing's purpose in life is to take feedback from customers & sales, market research, business needs, etc and make strong recommendations on how to capture more and more desirable customers. I think a more accurate statement would be that you think marketing is wrong...and as an engineer, the belief that "marketing is wrong" is kind of a given

Hi Jon, Thanks for your comments. It is nice to know our concerns are being taken seriously. I attempted to create a video of the behaviour I originally posted about, but cannot recreate it at the moment. I have just tested 2013, 15, 17 and 18 and all drag operations seem quite smooth (LiveDrag=False in my LabVIEW.ini file for '17 and '18), but these are for very simple test VIs not in a project. I have definitely seen the issue in '18 in the last month or so though. I currently use '15 for all serious projects and only tinker with '18 for personal projects. The grey selection rectangle introduced after 2015 does feel a bit sluggish though. One thing I did notice in my comparison tests is that the toolbar seems to refresh much more often in '17 and '18. Try this experiment: create a VI and drop down a single For Loop. Now resize this loop and take a look at the toolbar. In '13 and '15 nothing noticeable changes in the toolbar however in '17 and '18 the toolbar seems to refresh/redraw (flickers) regularly. If I see the other issues again I will try and take a video of it in action. 2018-08-28 23-26-24.flv

So I think part of the reason I hear people say the same thing of "Does anyone at NI even use LabVIEW for real projects?" is because every decently sized project I've worked on has these same types of issues. And it sounds like other users are in the same boat in some sense. If every real project you used LabVIEW on had huge compile time issues, builds that fail 3/4 of the time, constantly needing to delete compile cache to build, long load times when switching contexts, slow drag and drop, long save operations, and other IDE usability issues, then asking "Does anyone at NI even use LabVIEW for real projects?" starts to be a valid question. There certainly has been times when using NXG that I've thrown my hands up, and wonder why someone at NI didn't notice a glaringly missing feature, or a usability issue. Things that I'd hope any real developer would notice. With NXG there is at least the valid excuse that NI is prioritizing features. Sometimes I wish I could just have someone from NI follow me around all day and see the issues I have which aren't show stopping, but annoying enough to hinder development.

Hey Everyone, I was pointed to this thread by a colleague and wanted to answer some of the questions that were posed as well as gather more specific feedback on some of the things that were asked. First off, we do have engineers at National Instruments that are using LabVIEW for real world-applications. Our Systems Engineers and Applications Engineering Specialists work on some of our largest customer applications. They specifically create and work on real-world code. For LabVIEW NXG, we have a LabVIEW Lead User team that has met with a number of customers and converted their applications to NXG. Their team goal is to provide feedback to the NXG development teams and Product Owners to help us prioritize what we need to be working on. While a lot of my recent focus has been on LabVIEW NXG, I did want to follow up with the comments about the dragging performance of the LabVIEW IDE first brought up by Neil. I spoke with the developer of live drag about the behavior you are seeing as well as did some testing of it. The behavior you are describing when dragging objects across diagram boundaries (e.g. the drawing delay when dragging from outside a loop to inside) is actually intentional. It was a compromise designed in to help performance when dragging very large selections. The intended user interaction is that if the user really wants to see what the code would look like before releasing the objects, they could stop moving the mouse cursor. If we don't detect movement, LabVIEW will redraw the code. However, it seems this is being inferred is that there is sluggish behavior when moving things between diagrams. If you drag across diagrams and immediate release are you seeing a delay in moving the code? Your comment about seeing the same behavior when moving a single primitive makes me suspect that we aren't struggling to keep up from a performance stand point, rather the UX that we designed is not having the desired effect. Worse off, it sounds like it's having a negitive effect. As an aside, we don't need to do a full compile when we are doing live drag. Type propagation is just the part of compile that determines wire and node data types. When we are doing live drag, this is the only part of the compilation process that we have to do. Thanks for the feedback everyone. I know there were some other generic performance issues that were mentioned, and I don't want to give the impression that I'm ignoring them. I just wanted to focus on the issue presented by Neil first. Jon S LabVIEW NXG Product Owner

If you drop a dummy object on the diagram, then delete it, without wrapping those operations in a Begin Undo/End Undo transaction, it looks like it clears the Undo history.