I've found that all of my finished applications, that I am satisfied with from programming point of view, share the exact same architecture. I wonder if I came to an ultimate stage of LV wisdom that all developers share (of course I didn't) or if there is a way I could improve the code.
One of the apps I develop is for remote DAQ target management. I browse our mysql database for available targets, I choose whichever I want to probe. Then I download status files from our fileserver. I can press bunch of Shortcut buttons which open a browser link or run a command in command line. I can browse and edit the config file. I can send it to fileserver, backup the file to our repository and send a Slack note there. I can browse log files on the fileserver and append their content from longer periods.
What I try to say is that there is a lot of functionality in such an app. Every functionality has some data in it. There is ID of the selected target, paths to several fileserver folders, paths to files, access credentials. For config edits, I remember the original config content to compare the changes. There are lots of indices and status booleans and front panel references.
My first approach to use a shift register for each parameter. That worked for about 4 variables but I quickly ran of VIs' terminals and the whole application was a mess. The I discovered local global variables, then FGVs. Now I put everything in ONE GIANT CLUSTER (OGC). That works perfectly for one application. I have this OGC in an event structure and inside there is:
And all of the VIs in the event structure accept OGC data type. I also got used to replace big arrays with DVRs to optimize memory but I feel like there is still too much data copied to every VI while I utilise only part of it. The other problem is modularity, that the code is not easily transferable the other applications. So now and then I find myself coding things already coded.
I think that your answer will be OOP. If that is the solution (and there is no other help to me than to learn it), how does an app using it looks like? How does the front panel interaction works? What are the data of classes, how are they handed over to subVIs? I kind of understand the basics of OOP but I miss a thorough example of well-written complex OOP application, or a guide. Actually that is the same problem with standard LV code.
Help me please. Thanks.
Without seeing the code it is hard to really make any significant comments however based on your description I don't think your architecture is very good. As you already stated, you are passing ALL of your data to everything. You have subVIs interacting with the UI simply to get data. First suggestion for any application is to separate the UI from the main logic of the application. the code handling the UI should only concentrate on that. The code doing your real work shouldn't care or know anything about the UI.
OOP is definitely worth looking into. However, even without OOP you should only pass the required data to your subVIs and not your OGC. Your subVIs and module should be limited to a single task/function. If they are doing lots of stuff then you have not broken down your code enough. There are many well defined architecture that you can use. DQMH and actor framework come to mind. The various functionality in your tests should be separated. Your DB code should concerned with interacting with the DB. The logging code should only handle the logging stuff. If you start to break things down into well designed and focused modules you will find it is easier to reuse your code in other applications. OOP can help with this since you can simply add the correct classes for the functionality you want/need in the application.