Question to the UI design folks and LabVIEW OOP folks.
In a real-life project I am writing LabVIEW code to integrate several hardware systems, including a camera system. Sometime in the future, we expect to swap out our current camera model for a different one, and then likely more models after that. Naturally, my code already has a camera class inheritance heirarchy: very generic camera operations are handled by a Generic Camera.lvclass, while a few operations relating to model-specific camera features are handled by an appropriate child class (e.g. Camera A.lvclass or Camera B.lvclass). My example heirarchy only has two levels, but could plausibly grow to three or four levels in the future depending on various camera model features and similarities.
My question comes when the user needs to configure a the camera acquisition parameters via the LabVIEW software. My goal is that, when a user tries to configure a camera, they should see (and be able to edit) whatever set of Generic + Specific parameters are appropriate for the specific camera model that's in the system. The problem is that different parameters live at different places in the class heirarchy--very generic parameters (like exposure time) live at the Generic Camera level, while very model-specific parameters live at the Camera A or Camera B level.
I have attached my best attempt at a solution in an example project (run Top Level.vi and click the configure buttons). My solution shows the user two popup windows in sequence: first window is for the Generic parameters, and the second window is for the Specific parameters. This will work, but has two big issues:
(1) It's confusing for a user ("I only clicked the button once; why am I getting two popup windows?").
(2) It's not at all scalable if the class heirarchy grows to three or four levels (three or four popup windows in a row).
Anyone out there already solved a problem like this? Or can point to a tried-and-true OOP pattern/principle for solving it?
Thanks in advance!
