02-20-2012 04:17 AM
Hello All,
I am planning to build Labview code using the Producer Consumer & User events pattern, the application needs multiple user input windows for things like personal data, feature selection etc, there could be around 15 or 20 distincts screen/panels required.
The main question from me is... Is there a best practive approach to navigating/loading from one window to another etc, and also providing a way to to retrun to the previous window.
Also I may need need to be running some slow logging and control hardware in the background while navigating some of the screens, this seems like the producer consumer vi will be running in the background while the user input causes a load/display window event.
A simple Producer Consumer multiple winjdoow example would be very welcome. Thanks.
Regards Chris
02-20-2012 06:39 AM
02-20-2012 07:46 AM
I will second Mike's suggestion to use a central VI with subpanel(s). It is usually less confusing than multiple windows. Typically, the selection/navigation mechanism is on the left of the main panel, global info (like help) on the right, and the subpanel(s) in the center.
The advantage of subpanels/subVIs is that you can launch your subVIs and keep them active in the background, even though they are not being used. This means they will keep their state information and load into the subpanel almost instantaneously the next time you need them. For a short tutorial on subpanels, check out this link. Scroll down to the fourth reply for working code. The original code posted is broken.
Communication between your VIs or loops is typically done with either queues or event structures. State information in each should be shift registers in the respective VIs. If you have the time, I would highly recommend you learn how to use LabVIEW classes. The command pattern is tailor made for this kind of application.
Finally, avoid global data if you can. Global data is anything that you can get to from anywhere (globals, functional globals, etc.). Use of these can speed your development, but can also lead to sloppy design which will cause you major problems later. If you really need globally available data, use a data value reference. It is unnamed and requires a reference, which tends to enforce better programming practice. Yes, there are instances where you truly need globally available, named data, but they are fairly rare. You should only use them if you are experienced and really know what you are doing.