Leaderboard

The TL;DR is in bold. I want to add to the Conditional Disable structure a new built-in symbol that toggles when the VI's "Debug Enabled" setting is toggled. I've wanted this for a long time, but I finally got around to opening up the code to see what's possible. Let me take care of one question right away: I have no idea what version of LabVIEW this might or might not go into. So don't get excited. :-) Anyway... it turns out, what I'd like to do isn't straightforward. All existing conditional disable symbols are global to the application instance. The three built-in symbols -- bitness, target, and run-time engine -- are universal to the running environment. The symbols that users can define are in the project and target. In other words, if I want to know the value of any symbol, I just need the reference to the application instance, not to a particular VI. And, guess what, all the C++ code is therefore oriented around application refnums not VI refnums. *sigh* Now, it turns out that I can see a way to add the debug-enabled flag in a sort of sideways manner, and I would just hardcode that symbol as a special case in some parts of the code. RED FLAG! Alert! Developer has used the phrase "special case"! One of my colleagues likes to refer to the "0, 1, Infinity Rule". That is, there are either zero cases of something, one case of something, or an infinite cases of something. There's never just 2. Or 3. Or any other finite number. Basically, as soon as you are prepping the second special case, your code needs to be architected to accept an infinite number of such special cases because otherwise, you're going to build up a huge number of unmaintainable hacks over time. If there really is just one special case, then the code generally remains maintainable. One special case isn't a hack... it's just the special case of the problem you're code is solving. The second special case is a hack. I try to avoid hacking up the LV code base and developing more stuff that needs refactoring in the long-term, so I'm hesitating about working on this feature. With this in mind, I went to a couple of other dev and asked a question, and I want to ask the LAVA community the same question: Besides "enable debugging," are there any other VI-specific settings that would cause you to want to change the actual code compiled into the block diagram? I honestly cannot think of any. Reentrancy? I don't typically change the reentrancy of a VI on a regular basis. A VI is either designed to be reentrant or not... flipping that switch usually changes how the node is used entirely. Thread affinity? I can't think of any VI where I have ever wanted to sometimes have the VI in UI thread and sometimes have it in Exec System One, and where I wanted different code in those cases. No one else I've asked has been able to come up with any scenarios for that sort of thing either. Oh, the hypothetical COULD exist, but hypothetically, I could want the font on all my numeric controls to become italic whenever the VI is set to "run when opened". It ain't a real use case. :-) One person suggested that there might not be VI-property-related settings that would want to change out code on the diagram, but maybe there is a case for user-defined symbols at the VI level? Maybe. But, honestly, the Diagram Disable structure pretty much covers the "I want to change out the behavior of this VI". Yes, we all know cases where we have code on the left half of the screen and code on the right-half of the screen, and we need a separate disable structure around those regions... but that's just as probable as having that right-side of the screen dropped into a subVI. The setting then is not a per-VI setting, but it is either a per-project setting (which we have today) or a per-library setting... and that I can easily imagine a use case for. Having a per-VI user-defined setting just seems problematic if you dropped the code into a subVI and lost the link between those two VIs. I hate adding any feature that discourages people from creating subVIs as needed! So I'm rejecting that use case. And the library use case, while a good one, is outside the scope of what I'm asking about today. Go put it on the Idea Exchange if you want to promote it. :-) Which brings me back to the "debug enabled" setting. That setting can be programmatically toggled when doing a build (if you go into the custom per-item settings because NI doesn't have an easy single-checkbox for you) and frequently we do things while debugging that would just slow down a release build. Which means it makes sense to write code into the VI that could be either compiled in or compiled out based on the VI's debug settting, unlike any of the other settings. So... brainstorms anyone? And please be honest. Even if you want this specific feature, and you think, "Well, if I present this valid use case, it means he won't put in his hack, so I'm cutting my own throat," trust me... for the long-haul, you'd rather LV develop as cleanly as possible, for the sake of your own trust in it!

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.