X___

Are you forcing a conflict with Martijn Jasperse's H5labview package, or is this something made up by VIPM?

Free is maybe pushing it. Zero technical support without a SSP would be an appropriate model associated with open source. Of course this wouldn't prevent a vibrant community support (independent from NI) from existing, but this is not what the big industrial companies using LV would go for. They would remain NI's proverbial cash cows. I think the misunderstanding on the corporate side of why open source is beneficial for code safety and reproducibility is understandable, as I can witness the same ambivalence if not resistance in academia. As for NXG and webUI (or whatever they call it now), as discussed elsewhere, it looks like NI doesn't have the resources to bring the vision (whatever it was originally) to fruition, and their recent decision to abandon it will probably lead (or has already led) to morale cratering and talent effusion, so I wouldn't hold my breath... One thing I'd add to the list is this: stop the yearly versioning breaking backward compatibility. This is frankly moronic and the clear and only reason why this exists is NI pricing scheme. Adopt the scheme suggested in the first paragraph and this can go right away.

Sounds like King Louis the XIV's court. If someone had just pointed out that the natural next step of such an IDE was to introduce "text shortcuts" to diagram objects, they were quite a short distance from reinventing a text-based programming language. Brilliant!

Yeah, well, when was the last time NI asked users what they were expecting in a IDE UI? Or what they did or did not like in the mock up designs they were cooking up? I am sorry, I forgot about the "Idea Exchange" forum, which had so many transformative effects on the development of subsequent LabVIEW versions... Of course, ultimately this is probably not what killed NXG (the dislikes of a few old geezers for the IDE).

Following paul_cardinale's review of my demo, it turns out there was no glitch after all (well, in my understanding or attention level, maybe).

Sent as a PM. Also, is there a way to drop a Y Control in an array (or cluster)?

LV 2019 SP1f1 64 bit crashed upon closing my first Y Control... but seems to have recovered fine. So, I can now resize objects within a Y Control cluster, but there seems to be a glitch (race conditions?) in the Process New Value.vi: When the user changes the checkbox (for visibility) to True, the string is hidden and reciprocally. Am I missing something?

More on this saga, picked by chance in a Forums thread (https://forums.ni.com/t5/LabVIEW/Save-the-progams-user-interface-as-picture-or-serve-it-as-a-web/m-p/4106252?profile.language=en Future of Web Module In essence, the loop is looped and we are back to LabVIEW Web UI, released what, 10 years ago? The roadmap is pretty unclear past 2021...

cf Brian Powell referring to the "hackish" nature of XControls in the infamous NXG obituary thread...

1. I removed LVNewDialog.xml before re-installing 1.0.0.2 and got this: which, after I pressed continued, left the installer window opened in a stopped state, but at least now the help is back in the menu (but in Help>>Y Control, not Help -> New -> Y Control as you have it in the Readme.txt) However, the File>>New... dialog is now empty, so removing LVNewDialog.xml is definitely not the thing to do (putting it back resolves the issue but is missing the Y Control item). 2. Re-uninstalling Y Control Support now LEAVES the Help >> Y Control menu but nothing happens when selecting it: 3. Re-reinstalling 1.0.0.2 restores the Y Control item in the New... dialog box...but removes the Help menu! Getting somewhere?

Still can't seem to be able to access the Help. Certainly not in the Help -> New -> Y Control -> Y Controls menu and the chm file still doesn't work for me? It seemed quite straightforward when I first installed it, but maybe the UNinstall step messed up with something? I just uninstalled 1.002 and tried again the release from post 22 and am without an easy way to find Help within LV (and the chm file is not working anymore as a standalone) 😞

How do I access the help again? It worked fine in the previous version, but is nowhere to be found in the new one, and the chm help file in the installer doesn't work as is...

One more of those dead links on NI's website then... and no information whatsoever. Strangely enough, I never got a "We'd love to hear your feedback" pop-up on that page. 🙂

Not if you select VHDL

Playing around with it. It looks like, as for X and Q controls, compound controls need to be bundled up into a cluster. As a result, the facade is rigid, in the sense that when dropping an instance of the Y control, I cannot adjust the components of the control (or the whole control itself for that matter) unless I modify the definition of the control itself. This is fine for a "one of" control, but somewhat of an issue for something intend to be generic. As an example, I was trying to try out the package with a simple string with visibility checkbox. Once dropped on a FP, neither the checkbox nor the string can be resized. This type of ability (or lack thereof) is one of the things which immediately cooled my enthusiasm for the X and Q controls. I may be missing something though.

Online shopping for this product is currently unavailable?

I wouldn't use a language which is based on a lot of inaccessible C++ code for mission critical software... like driving a space rocket, for instance. I have encountered a lot of "corner cases" in the math routines which had probably some trivial algorithmic flaws at their core, but this was not possible to detect (let alone correct) until I drove the code in the ground, so to speak. One more reason to open the belly of the beast.

That may explain things then. I am not a channel wire convert, use VIM occasionally and have stayed clear from classes (and thus interfaces). Which I guess excludes me from the conversation? Some dialogs are obviously LabVIEW-built, and have aged pretty badly. The GSW is a recent example of accelerated obsolescence. But as far as I know, the universal answer to requests and suggestions has been: "NI has other priorities and limited resources". How could it be otherwise indeed? Maybe, just maybe, tapping in a free multiplier of resources could change things? It is not that there are only negative examples out there of open source programming language development... But I'd understand that a scalded cat fears cold water.

Sure, why not rewrite Linux or Android in LabVIEW too... 🙂 XControls are not standard LV objects. Can't put them in array, they have all kinds of limitations, and while I understand that they were created at great cost and with the best intentions, they essentially failed (I think I have developed one and concluded that this was not worth the effort - in large part because of the impossibility to array them). I'd say pessimism seems warranted after the failure of NXG and the complete lack of a clear roadmap (this is what I was referring to with the term quixotic - with a typo). I have since cut NI some slack and understood that little guys like me are of no monetary values to them. Fair enough and in any case, this is not the type of programming language I can publish code in since it is hieroglyphics to most. And even that at some point will have no value, as we will just tell Alexa the general features we need in our software, maybe draw a GUI mock-up and a DL network will generate the code...

There is a problem right there (in the flash light story), but who is really surprised about it? Of course there would be a cost to open sourcing the code: cleaning it up and documenting it as the team fixes things up in the upcoming releases is something that would be expected from a pro team anyway. They wouldn't have to accept any and all contributing candidate, and they wouldn't have to commit any and all contributions. But they might get some good feedback from dedicated believers (see e.g. https://openjdk.java.net/contribute/). At worse none, but that in itself might be a good indicator for management to take a hard look at LV's relevance. They could spin-off improvements to control/indicator modifications to the community and focus on the things that matter most to their core business. You'd be surprised how focused debuggers would be at squishing those pesky bugs of yore... not mentioning expanding the capabilities of LV. There is no guarantee that LV would eventually rule the world (I don't think anyone of us has ever had this dream). But maybe it would give it a chance to not look hopelessly outdated. The real obstacle seems to be the "NI culture". I have no idea what it is, but the recent past has painted it has rather quitoxic if not readily toxic.

This is material for the Ph D thesis on the NXG fiasco I was fearing (in another related thread on this forum) would never be written... and is now lost to the microcosm of LabVIEW Champions (I understand knuckleheads like us were not intended to be privy to this juicy stuff) It seems that one way to give a future (or definitely burry any hopes for LabVIEW at the sight of the quagmire) would be to open source it.

Maybe that is relevant: https://www.cmlviz.com/recent-development/2020/10/29/NATI/national-instruments---announced-workforce-reduction-plan-intended-to-accelerate-its-growth-strategy-and-further-optimize-operations-cost-structure Another variant: https://www.honestaustin.com/2020/10/30/mass-layoffs-at-national-instruments-remedy/ ("Thursday, he said that sales staff and administrative staff would be most affected", so maybe unrelated to NXG's demise after all...) And from the top dog's mouth: https://www.reddit.com/r/Austin/comments/jkyid6/ni_is_laying_off_9_of_its_global_workforce/

Isn't this serious stuff though? Most of us may have had disagreements with NI on some of the paths they had chosen to go down to, and were lamenting the crawling pace of their progress, but at least we all agreed that the current LV IDE/UI development toolset was outdated. The official statement (by two top brasses, not a mere webmaster) is not particularly crystal clear as to what is forthcoming. Coming right after the Green New Deal campaign and in the midst of the pandemic, it might just as well be a forewarning of major "reorganization" within NI... The surprise expressed by AQ in a different thread would seem to support this hypothesis. At least it gives me something to speak about in my next "how do we use LabVIEW in the lab" intro session...

Can't say that the rationale for the decision is put particularly convincingly... We'll have to wait for the dust to settle to really figure out what this corporate double-speak means. Do they even know themselves?

I have been using Parallels for a long time. It works but it also hurts (more on this below). As far as subscription vs none, there used to be limitations to the one-of version in terms of number of cores and max RAM (this might have changed, but I don't think so). This is a problem when you have a multicore machine and you end up limited to only a few. There are some additional perks coming with the subscription version (including updates, and a la LabVIEW, the corresponding bug fixes). Be warned that their support is nowhere close to NI's, which is a problem when something fails badly (and it will, potentially). Thus, do not upgrade to the newest version until after careful monitoring of their forums, as my experience has been that it can sometimes completely fail and corrupt your VM. Which brings me to the most important advice (independently of the upgrade step): do not save critical data - e.g. VIs- as part of you VM (unless you want to backup a multi GB blob every day as part of your Time Machine routing - the VM comes as a humongous file that you will probably want to exclude from your backup routine and only save every now and then - typically before an upgrade), but instead, take advantage of the ability to share data between your VM and the Mac. This way, if your VM becomes corrupted, it's just a matter of getting an old copy of it (with only the system and apps, which typically don't change that often or can be easily updated if needed). Your data files will have been on the mac side of things all along and unaffected by the Parallels fiasco. It has happened to me several times. As usual, YMMV. As a note, I am not sure this is the best time to switch to a Mac, with the Apple silicon transition, which will at best emulate Intel CPUs, and as far as I know, Parallels adjustment to this is still in the work. I am personally switching to a Thinkpad... and in the long term, Python 🙂