Leaderboard

We are also fighting the problem via the scripting tools. Automating the busy work and abstracting that away from junior developers. In our experience, explaining the concept of user events and how the information is transmitted from DQMH module to module has never been the problem. The problem is when the junior developer has to remember all the steps needed to create a user event. With the scripting tools we automate most of the busy work and let the junior developer do the final connection of editing the event structure case to handle the specific event, but they don't have to worry about remembering to add the new event to the typedef, to the destroy events, to the create event, etc, etc. standardization was a big part for the Delacor team deciding to use the NI QMH as our springboard. The producer/consumer and QMH templates were the ones we realized most of the junior developers we encountered were familiar with. This is one of the reasons the Main module looks a lot like the NI QMH template, with minor exceptions. Glad to know that DQMH is one of your options for your future projects. Let us know if you decide to go with it. Also good to know that you find both the videos and the scripting tools useful. This inspires us to continue to create such tools for the community.

The lavag json library (https://lavag.org/topic/16217-cr-json-labview/) is pretty good and seems to have the capability to avoid issues like this. If you need XML, GXML and jki easyxml would probably also handle the variant (although I haven't tried it which I have with the json library).

I honestly don't know what you're talking about, I get that it is a joke but I don't get the joke. You can't easily just open an XNode. If there a template VI (like most of mine have) you can open that but actually opening the code generated requires some INI keys. Yeah that's part of the problem, the only "standard" on making an actor design at the moment is the NI Actor Framework. This standard is not catching on in the advanced developer community. I can speculate why but the point is, if standardization is key to adoption, then all of these different designs might be adding to the noise. Which is hard for me to say because lots of what i see in the DQMH, and JKI Objects I like a lot. And will likely be using one of them over the Actor Framework. The value of the DQMH videos, and scripting code should not be understated. Conceptualizing, and designing actor based software is confusing at first. Being able to say "Here watch this video for a few minutes, and you'll get the basics." is going to be a very valuable tool.