Leaderboard

All I ask is that my bugs be obscure enough that I find them before my users do and few enough that I have time to fix them before my users catch up. :-) References: the last weapon in the arsenal of the G master but the first refuge of the novice. Except Mikael. I cannot explain Mikael. Karma must love him because, by rights, his reference-heavy G code should be both more buggy and less performant than I know it to be. If any among us do seek to walk The Path of the Referenced Object, you would do well to step in Sensei Mikael's footprints for he has found the safe route.

After looking at your code, I can see what it is you are trying to do. It looks like an attempt at the old "Magic Framework of Massive Reusability". It's a nice to think you'll have to build this only once and then reuse it everywhere. You'll have these convenient VI's that automatically launch at all three class levels that allow updating the data at their level for all the objects in your array. The question new LVOOP or even just new LabVIEW programmers usually ask is something close to: "Why do I seem to keep building the same program over and over again?" and/or "Isn't there some way I can build some magic modular framework once and use it everywhere?" Many have tried, including the Actor framework. Some of the newer ones work well, but all are messy at the bottom, in my opinion. Even if you were to get this hierarchy to work, how convenient would it be to use, really? Everywhere it goes, it will need three sub panels. My advice would be to forget the "ModifyUI" method for your classes and take a traditional approach of putting the controls for modifying your class data all at the same level on your main front panel. You'll suffer some aggravation at having to build that top-level VI over and over again, but your programming style will be easy to understand and debug. Keeping it simple is usually the best approach.