Aristos Queue

This is false. Where did you get this impression? I don't think I've heard anyone propose this. The forward direction from current platform to next platform is certainly a possibility. I'll propose it to the team.

Stuxnet can be just as easily distributed on CDROMs. The danger of Stuxnet is not in the media. It's in the provenance. For Stuxnet, people found USB drives in the parking lot and used them. It would be the same if you found a CDROM in the parking lot and popped it into your computer. If you really have a blanket ban on USB drives, you may have to download LabVIEW instead of installing it from media -- it doesn't fit on a CDROM anymore, so we don't ship them.

Exactly how far apart the two dialects are and whether they constitute different languages is a judgement call that shouldn't affect the forums. If the person's question does hinge on something that is platform specific, then I would direct them to the specific forum. If it is a more general question, I would not. What I do not think should happen is somehow that all the years of good commentary on software design that LAVA has built up should suddenly be relegated to an "old news" bin just because the UX got a rewrite. So the main headings of Application Design & Architecture Object-Oriented Programming Remote Control, Monitoring and the Internet Certification and Training Database and File IO Calling External Code Machine Vision and Imaging Real-Time Embedded Linux Apple Macintosh I would not fork. The platform-specific ones of User Interface VI Scripting Application Builder, Installers and code distribution Development Environment (IDE) Source Code Control TestStand I would suggest forking. Similarly, I would not fork "OpenG" -- the API should be the same in both dialects. Apply same rubric for any other subforums.

Following up on that: http://www.ni.com/white-paper/3574/en/ Search for "multiple inheritance".

None whatsoever while I'm working here.

Given that G is the same language in both -- the compiler and execution system are [mostly] the same -- I suggest creating a "LabVIEW NXG Development Environment" section. That way it is clear that architecture questions go in the version agnostic section (since the right way to write code shouldn't depend upon the environment), but UX changes go to the version specific. There will be some muddiness as NXG develops (right now, no classes; in the future, gaining components, something the current dev environment isn't planning to develop), but for the most part, I think this would serve best. For the record, I've got a similar conversation happening inside NI about the Idea Exchange. ;-)

FYI... found a workaround for right now... right-click "Open Front Panel" will display the clone.

Well... that's unexpected. And wrong. I'll file the bug report.

To the best of my knowledge it works. If it doesn't for some reason, use a case structure with a constant wired to the ? terminal. That will still get the type and still not create the event unless you need to. Thanks. It's a brand new feature, so I'm nervous that we've missed a use case somewhere. So far, so good.

You'd have to ask a NXG UX designer those questions. All my NXG work is behind the scenes. I don't speak for any of the design decisions of anything you see on screen. In some cases, I can tell you "what" but rarely can I tell you "why". Try posting your questions to the CAB forum or use the feedback function that Mads mentioned above.

ShaunR: Your code looks like it is working way too hard. Here's a significantly more performant version -- so you don't do the extraneous creation of the event refnum all the time. Note my comment, though... I preserved your behavior in this code, but I'm curious why you have the feedback node... why would you ever want to return the same event registration refnum multiple times? That's a bug in most G code.

Exactly correct. The nodes are just regular subVI nodes. The instances are created using the same tech as Express VIs.

What? There's nothing about OO in the picture I posted.

Welcome to LabVIEW 2017. It'll be even better in 2017 SP1, but this works for now.

You'll have to make your own call on when to add support for the new and when to drop support for the old. That's my only guidance. The LabVIEW Tools Network team may have more specific feedback. You can ask them on the toolkit dev forum: http://forums.ni.com/t5/LabVIEW-Tools-Network-Developer/ct-p/7009

The latest guidance, given to both customers and to LV R&D: development in the current platform will be increasing and will continue for the next few years. Not just bug fixes, but actual feature development. When NXG reaches maturity such that it is capable of being a full replacement for the current platform, it will be renamed as just "LabVIEW" and the current platform will move to some other name, TBD. That "full replacement" version is what some people call the "parity release", although parity is a bit of a misnomer since some features are being deliberately left in the past (front panel data socket, "Enable Database" on subVIs, to name two). If you hear about NXG reaching parity, it means the point where our most advanced customers can fully do their jobs with a UI that they're at least grudgingly happy about (Hoovah's graph of user happiness earlier in this thread is quite accurate, IMHO). From that rename point, there will be several years of support for the current platform: limited bug fixing and validation for new OS editions as they occur. How many years exactly will be communicated at that time, but it will be multiple. That's the summary. Now, to put some details behind that... I personally have at least 2 years worth of new features in the pipe. My personal attention is split, with about 15% to NXG and 85% to LabVIEW. There are a couple of teams with 2018 features, and I'm expecting to see a few more on-boarding for that and 2019. The majority of developers will still be working on NXG, but we will see a lot more life in LabVIEW. The new features will mostly (but not exclusively) focus on language developments, not editor developments. The language enhancements of channels and malleable VIs are both going to see improvements going forward. There are four new structure nodes being kicked around, one of which you've seen if you've seen the NIWeek or CLA Summit presentation on 2017 malleable VIs. For the other three, ask @lordexod... long experience tells me he's probably discovered their early footprints in the code. ;-) I said there would not be many editor developments. That's because the whole inspiration for NXG was to provide a new editor because the code in the current environment makes editor enhancements particularly cumbersome (30+ years of development makes for a lot of module coupling). Given that, it makes little sense to try to forge ahead with most editor improvements. But there are some editor enhancements that are worth doing, as you see from the live drag and the remove space enhancement of the last couple versions. There will be more ahead. Because the compiler and execution engine are shared between LabVIEW and NXG, there's a team working on optimizations to both of those, so you'll see improvements in those areas. The interest in improving run-time load speed has lead people to discover ways to improve load speed in the current editor... you'll see some of those improvements in 2017, more in 2017 SP1, and another few in 2018. That's as much signposting of the road map as I can give at this time. I hope this information provides at least some reassurance to the LAVA community.

This theory is correct. (I'm just the messenger. If you want cross-platform development, talk to your local NI sales engineers and other NI feedback venues.)

Split design mode, yes, where you can see both panel and diagram. We don't maintain an in-memory XML form, and if you look at the save files, directly editing the XML is a fools' errand (at least for me... I've tried to doctor several such files over the last few years). So if you're asking for an XML format, there isn't one.

Nope. Plain subVIs.

As in, when caller leaves terminal unwired, subVI has behavior X. When caller wires the terminal, subVI has behavior Y. This is distinct from simply using the default value of the terminal.

There is a feature I've wanted in LabVIEW for a long time, pretty much since I started programming in G: The ability to have an unwired input terminal have meaning. Currently, if you leave an input terminal unwired, you set it to Recommended and you give the control a default value. That doesn't really mean the user left the terminal unwired... they could have wired the default value. That doesn't really help when, for example, all possible integers are valid values for the input. You end up having to add a second Boolean terminal for "should pay attention to integer?" or something like that. Even when you do have a valid sentinel, you may have to add code to check "is the input value the sentinel?" in the middle of your executing code, which is a small but annoying performance hit, and one that can ooch up over time. Think of how many times we check error input terminals and how much of that code could be dead code eliminated if only subVIs generated code specific to their callers. That's a *minor* example. There are a lot more interesting algorithmic changes that are possible for an unwired terminal... some of the built-in primitives of LabVIEW have very different behavior when inputs are left unwired. Currently, if you leave an output terminal unwired, LabVIEW doesn't care... the value of that output gets computed anyway when the subVI is called because the subVI has only one code path. This has lead me to have to have extra terminals on input for "should compute output X?". You can fix this sometimes by marking the subVI to be "inline" and then when you turn off debugging, the computation code likely gets dead code eliminated. But not always. If the computation involves a refnum, it won't get dead code eliminated. And if there are interim data structures along the way that you populate, those will still get built up if they're part of a downstream terminal that is wired. The compiler probably (IMO) will never be smart enough to analyze and do that level of elimination until the compiler is sentient. So some sort of computation here would be valuable, I think. I've investigated this before and always hit some limits. I'm thinking I might make another run at figuring out how this could work. No promises, but there's some new ideas out there on code optimization that I might be able to leverage. The unwired output case is pretty straightforward... I'm not too interested in unwired output cases unless you have one that is radically different from "this output is expensive to compute so I only want to do this part of this larger algorithm when that output is wired". I am interested in unwired input use cases. So as part of my brainstorm on this topic (and to gauge whether or not this would have benefit to users other than myself!), I'm curious to hear about any VIs y'all have written where being able to program in unwired terminal behavior would have been useful for you. There's no deadline on this. I am just sort of musing on this topic lately. I don't know if it will lead to any LV features. I just want to explore this particular topic more.

ShaunR: I don't know enough networking to know what a proxy is, much less the difference between an opaque and a transparent one. That makes it hard for me to file bug reports when I read comments like this. Can you write up more details about what the issue actually is? I might be able to get someone to look into the issue if I could describe it properly.

The right way would be To More Specific, but there isn't any VI Server class added for this structure node. I assume Jeff K just forgot to create it.

> For my own interests is there some decent documentation about the undo stack and how that works? Not really because there isn't much to it -- if you do edits to the VI when there is no transaction in progress, the undo stack gets wiped. If you call Begin Transaction, all edits are logged as part of that transaction until End Transaction is called. I can't think of any other details to document. Do you have specific questions? > So in my original plugin I did not modify the VI in the build menu part of the plugin and it still crashes. There may be something else going on. Keep in mind that this structure wasn't added fully to scripting -- there's no specific scripting class for it, so there may be something in LV that is getting confused about its type. This may be a more fundamental issue that has to be fixed in LV 2017 (can't add new scripting classes in SP1 and patches).

> Doing so will always wipe the undo stack. And since you're apparently sometimes wiping out the thing that LV is right clicking on (the Remove Frame could remove the current frame), I'm guessing that can crash. That's not an operation I ever contemplated anyone even attempting, so I never tested for it. Don't modify the VI during the builder VI and you should be fine.