Shared Variables vs Globals

[Dave_Thomson]

   I started a large project recently and decided to make use of Shared Variables.  :I need some network communication between LV apps, so that is the main reason, but I decided to put them to the test by also using single-process Shared Variables instead of globals.  (Yeah, yeah, globals are evil.  blah blah blah.  I'm not really interested in dogma here.  Suffice it to say that, IMHO, there are still a few times and places where globals are appropriate and useful.)
   My project is fairly modular, and the main control program launches numerous other top-level programs.  The problem is that whenever one of these top--level programs (or the main program) is launched, the Shared Variable deployment window pops up and does its several second initialization.;  If this happened just once, when the top level program launched, it would probably be acceptable.  But having each dynamic VI go through this gets annoying.
   I'm using 8.2.1.  I haven't tried 8.5 much yet, but at least in 8.0 and 8.2, you can't search for Shared Variables.  That is also annoying and can lead to maintenance issues.
   So now I am considering replacing all the single-process Shared Variables with good-ole Globals.  A couple of the VIs in the system will still use networked Shared Variables, so they will still cause the deployment window to pop up, but it will be much less frequent.  And I'll be able to search for the globals and make sure I'm using them responsibly.
   Does anyone have any other ideas on how to minimize the deployment window?  Or ideas on development patterns using Shared Variables?  Preferences for Shared Variables vs Globals?

Thanks,
    Dave

[Ben]

Hi David,

You did not mention the "Auto-deploy" option.

DId try shutting that down?

Ben

[Graziano]

Hi!
   Since I have LV 7.1, I cannot use shared variables....

    Anyway, I often use global variables, and... yes, they require attention, but I don't think they're evil... using good design pattern can avoid many programming errors.

    Of course, he new shared variable make people loose interest in functional global, which is too an interesting object... and you can use it in older versions of LV. What about it?

graziano

[Dave_Thomson]

Ben,
   Wow, you are quick.  And thanks.  Good catch.  Turning off the auto-deploy removes the dialog.  Nice, but now I have to figure out how the SV's are going to get deployed on each installation...  I haven't fully digested how SV's really work, especially how to best handle the deployment issues.  This project will be installed on a number of computersand used by scientists, not LV programmers.  So I need a reliable way of setting up the deployment.  Perhaps it is just one more step in the installation process..  That assumes that all the SV's are defined when the program is first installed  The program is very modular, so the end-user will be able to copy new modules into a certain directory and be able to use them right off the bat, no extra programming.  But if a new module contained a new SV, it wouldn't be deployed...
   Any suggestions for searching?  I haven't tried it yet, but it seems that deleting a SV from the project is the only way.  That causes an error to occur at each instance of the SV.  Assuming all the project VIs are in memory, you can then use the error finding to locate every instance of where the SV was.  Of course, it isn't there anymore.  Minor issue...

Graziano,
   Thanks for the ideas.  I do use functional globals a lot as well.  Very nice tools.
   I was really trying to transition to SV's so that I could use the Networked version.  I was using Single Process SV's instead of globals just as an experiment and to potentially leverage other SV features for them in the future.

Regards,
   Dave

[Ben]

Hi Dave,

There are new invoke nodse for programatic deployment of SV's.

Last I looked, deploying SV to machines that are not known at development time are not straight forward.

The SV's have to be hosted somewhere and depending on the app it may require multiple SV-Engines to up and running.

Ben