Leaderboard

As a consultant I have to work with whatever code my customer has developed. Some of it does indeed take several monitors to scroll across and I just have to deal with this. The IDE should not choke or do "stuff" constantly while I am editing. Also, as is pretty common during development my code spends a lot of time broken as I develop or refactor stuff, and I have to deal with missing VIs all the time as I integrate other team members code back into the main branch. As LogMAN pointed out, the behaviour of the selection rectangle is so much quicker in 2015 (at the expense of the "amazing must have could not live without" feature of shading the contents of the rectangle). I bet ShaunR is having a quiet chuckle about this whole thing as he gets to use 2012 or something like that. Sorry if I am coming across angry, but I am. LabVIEW is not exactly a new immature product that is given away for free. We really should not put up with this rubbish. If I have to wait for my IDE to draw a shaded rectangle, regardless of the quality of code underneat, something is deeply wrong.

I can present less complex VIs with the same behavior, more or less intense. @Neil Pate likely also doesn't use broken VIs for real world applications and gets similar behavior. The VI in my video is certainly an extreme case that is not fit to be part of any code base, but it serves as a good example for how bad things can get. I don't expect that VI to work flawlessly, but it wouldn't hurt trying to achieve that, even if that means disabling fancy stuff for more complex VIs. Here is the same VI in LV2015 for reference. To be fair, scrolling is as slow as in LV2017 (or vice versa), but the selection box is so much better. 2019-02-01 21-33-45.mp4 The VIs I'm normally working with are much smaller than this one. Most of them fit on the screen, so scrolling is not an issue for me. The selection box, however, is a different story and part of my daily work. It being slow is a red flag.

Wait, what about the person who already had the name Bryan?

There should not be, adapting to type is all you want and thats what vims do. As pointed out, queues are not a runtime-dispatchable type in the same way you cannot dynamic dispatch off a boolean or an array. The contents are irrelevant. Its worth noting that vims support dispatching based on method name rather than class hierarchy. There are examples of using vims to make lvclasses act kind of like interfaces (ie if you have two separate hierarchies with a method "Get queue" which returns a thing at connector pane position 3, you can put that in a vim and it will adapt, including if that outputted thing has a different type). As a side note, you can and should wrap the queue status and index primitives inside of a disable structure.

That is very unfortunate. NI really needs to work on that. For reference, I found a complex VI here and used that on my private notebook (decent hardware, enough for LV2015). This is what it looks like on my end (using LV2017.0f2). 2019-02-01 20-59-05.mp4 It's a bit faster without recording of course, but not much. Also the CPU consumption is about 20% while dragging, which is way to high in my opinion. How did that ever pass testing phase? Looks to me like they never tested with more complex VIs like this because it works fine for smaller (or empty) VIs. Anyway, it seems that the dragging operation in LV2017 is not a O(1) operation. More like O(n) where n is the number of objects on the block diagram. They probably check every object during the drag operation to figure out which one to highlight. Works better on the front panel but that is probably because there are less objects on the FP (i.e. no wires).