Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/29/2018 in all areas

  1. 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
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.