A Scottish moose

This is a good summation of the problem. Thanks for sharing!

Ehh why not... <gets chair and looks intensely at camera> I think that NI will sell in the next 2-3 years. I agree with X on the churn rate. There's zero chance NI comes out on top in the long term with this plan. NXG is dead; LabVIEW as a competitive language is no more from a professional standpoint. It's firmly an enthusiast language now. That means like other enthusiast languages it's user base will continue to shrink from here on out. Now you've got two options to deal with this problem; embrace it or hasten it's demise. NI is obviously going with the later. 2-3 (maybe 5?) years of increased revenue while people work their way off the LabVIEW bandwagon (which they were going to do anyways when NXG was nuked) and then they are moving on. It's possible NI just understands the 'make hay while the sun is shining' concept and are going to get every value out of the product in the next half decade because, either way, LabVIEW is dead weight on the company in 5-10 years. The other possibility is that subscription revenue has a higher impact on company value (on paper) than on-off sales. I think subs are a 2-3x multiplier on estimated value. If NI is looking to sell, moving everything to subs and holding for a couple years until they hit the peak of the revenue curve in 2025 and then shopping for a buyer makes the company look 50-100% more valuable than it was in 2021. All that's conjecture and theory. I'm more than happy to be proven incorrect, but I believe I am saying the quite part out loud here and I think that's a good thing. (I hope) Best Tim

My approach has been Class based inheritance. Have a parent class that accepts the messages in a VI and then overwrite that VI with your children classes. Using inheritance allows you to make a decision on who gets to handle the command first. The youngest class in the hierarchy gets a chance to handle the class first before you pass it up (or not). I find that it makes it easy to handle the "What do I do if both controllers handle the same command differently?" As an example. MsgHndlrParent.lvclass:core.vi ControllerChild1.lvclass:core.vi ControllerChild2.lvclass:core.vi Child 2 would attempt to handle the command in it's overwrite of core.vi, if it can't send it to Child 1:Core.vi, and if child 1 can't handle it pass it to MsgHndlr for error handling. Hope that helps! Tim

Perceived_IQ = (150-age)

I have always found that the core LabVIEW community to be kind and welcoming and more than willing to support and bring up new developers. This is one of my favorite things about LabVIEW; that people actually have a passion for the language and the culture that it creates. You write Python because everyone else writes Python. You write LabVIEW because it's a unique experience and sharing that experience is part of the package. The Architect's Summit every year was one of my favorite weeks of the year for this reason (aside from the free food ). The people on this forum are some of those most responsible for keeping that community expressly *not* like other programming communities out there. It's a big selling point for the language and why I think it was so successful (IMO) in the mid '10s.

As a mid-career guy I think I can speak for some of the younger developers in the world. If you are working on a programming problem I think Googling "How do I do <this> in <programming language>" is basically the de facto solution to that problem. Weither you get the answer from YT, Reddit, Twtr, IG, FB, etc is irrelevant as it the first answer on Google always wins. This has been true for me for the last 10 years a least for whatever that's worth. If I could be so bold... I actually think one of LabVIEW's challenges is that it doesn't take well to posting on text forums and requires PNG'd meta files at the least to pass information around. A 'dump VI to text' option similar to what was used in old video game saves (or Factorio blueprints if you are familiar with that game) would vastly improve the share-ability of the language. I might be showing my novelty here if this already exists. it would do a ton of good for the language.

I have frequently wondered on the 'Make it possible, but really inconvenient' approach to software legacy support that has become the norm amongst many large software corporations in the last few years. I'm sure there is a reason for taking this approach from the seller side but as an enthusiast/developer/consumer all I see is bad customer service...

I hope this is true. LabVIEW is the only language I enjoy programming in. I had thought community edition was the solution to this problem but I've basically seen LV interest continually wane in the 10 years I've been using it.

Corp gave the rubber stamp so I'm planning on being there.

Harsh but true. To his credit it takes a brave presenter to take live comments, especially when they are posted directly behind you.

Hey everyone! I've looked through google and the lavag forums for this problem and haven't found much so I thought I'd ask and see if anyone had some ideas. Problem: I have an executable that is launching applets from several different PPLs. I am defining what PPL should be loaded by passing an INI file as command line arguments and also providing any other important start up information in that file. I've been trying to also force the icon on the application to set so that, depending on what the user is doing, the icon matches the process that I'm presenting them. Originally I thought this to be rather trivial as LabVIEW provides an invoke node to set the icon but after attempting it (and then checking the documentation) I realized that it is not available at run-time, (also it doesn't support .ico files according to the docs) http://zone.ni.com/reference/en-XX/help/371361R-01/lvprop/vi_set_vi_icon/ My hope is that I can force the application icon on the start bar and the title bar to match the .ico file that I'm providing to LabVIEW from the ini file. Any thoughts on this? I assumed it would be rather simple, just a function call to the right property/invoke/activex node but I've not come up with much at this point Thanks for your help, Tim

Hello everyone, TL;DR - Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework? I've got some library code that would be valuable but the project itself doesn't justify AF. I'm brainstorming ideas for a tester that I'll be building over the next few months. The project that I'm currently winding down is an Actor Framework test system that has come out really nice. Part of the project was an actor built to handle all of the DAQ and digital control. The main actor spins it off an tells it when and what tasks to launch. It send back data and confirms commands, uses Dynamic events to keep up with the generated signals, and uses actor tasks to ship the data back to the controller. Works amazing. Nothing revolutionary for sure but very handy. This next project doesn't really need actor framework, it's much smaller and has a lot smaller list of requirements. That being said I'm curious about integrating my DAQ actor (Dactor, because who can resist an amalgamation?!) into the project. Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework? Is this even possible based on how the AF tree is designed to work? Thanks for reading! Tim

Anyone know of a way you can do a ctr+drag on the block diagram (adding or removing space) that only impacts the current structure? I find myself wondering if this functionality exists often enough I thought I'd ask. Basically if you have a for loop inside a case structure is there a way to do a drag inside the for loop and grow that structure without impacting the case structure size or position? Thanks, Tim

Yes. They are... however this was out of the classic palette. Perhaps you've taught me something new. I was under the impression that only system dependent controls are in the systems palette but I bet you are correct. The system button in the classic palette is OS dependent. Good catch Don't listen to my previous posts then because my conclusion was incorrect. Also thank you for your observation. Tim

Update: I was able to replicate the original look with a 'Flat Square Button' and some color matching in about 5 or so minutes. Just be aware that if you move to sp1 of 2016 some of those graphics will change on you. Replicating them isn't a big effort however. Cheers, Tim