Can I Register a Global Variable Object Value Change in an Event structure?

[Jed_Davidow]

I have revealed a global variable to the user via a sub panel, so that the user is directly modifying a global variable panel.  This is working very well for this application.

However, I would like to react to this in an event structure.

I attempted to register the GV's Panel->[Controls].  This appears to work, but changes do not generate an event.

I then tried to register the controls individually.  This also was allowed in code, but did not work at run-time.

Is this possible?  Any ideas on how to make it work?

[mikeporter]

Why the global? Put a normal vi in the subpanel with a value change event on a control on the frontpanel. When the front panel value changes write the new value to a named notifier or perhaps a userevent.

Mike...

[Jed_Davidow]

Thanks for the solution.

But I'm still curious as to whether I can trigger an event off the global directly.

[Mark_Yedinak]

---

@Jed Davidow wrote:
Thanks for the solution.

But I'm still curious as to whether I can trigger an event off the global directly.

---

Interesting thought in the theoretical but if I were you I would ditch the global. There are tons of threads why they are a very poor choice to use in an application. And while you might find it is possible (I can't say because I never use them nor do I ever want to) it doesn't mean you should. It's possible to to stand outside holding a metal pole in a lightening storm but generally it isn't a very good idea.

[Jed_Davidow]

HI Mark,

To me, when I hear people say "I never use this because of the potential for misuase" I think that it's like saying "I never use C because it's possible to write data beyond the end of an allocated array and blow everything up".

Like any other tool, I believe there is a right way and a wrong way to use global variables.  IMHO, making a principled choice to *never* use them, even when they are appropriate and convenient just reduces the tools you have available and needlessly increases the complexity of the code.

[mikeporter]

I can't speak for Mark, but for myself I also don't use globals but it's not because of the potential for abuse... It's because if you create your code correctly they aren't very useful...

Mike...

[Jed_Davidow]

Example:  Let's say you have a subfolder somewhere, determined at program startup and then never (or seldom, without race conditions) changed.

While I know there are several methods to allowing access to this value throughout your code, you are saying that the potential for abuse is enough that you avoid using a global at all costs?  What is your preferred alternative for something this simple (and I am making the assumption that the code is a little more complicated than just a single private data cluster can handle).
 

[Ben]

---

@Jed Davidow wrote:

Example:  Let's say you have a subfolder somewhere, determined at program startup and then never (or seldom, without race conditions) changed.

While I know there are several methods to allowing access to this value throughout your code, you are saying that the potential for abuse is enough that you avoid using a global at all costs?  What is your preferred alternative for something this simple (and I am making the assumption that the code is a little more complicated than just a single private data cluster can handle).
 

---

An Action Engine perhaps?

There are more reasons but two that come to mind are performance and scalablity

See here for a thread where I last abandoned Globals due to performance.

Re: Scalablitiy

Yes you can get away with a global but you have to know where and when the global is updated and take that into concideration when adding to it or accessing it in more than one place. Get even more complicated if you have dynamic VIs using the global and you don't realize it.

If AEs are used insted of the globals, the built-in protection is there from the start and you can "enhance-away".

Since they are limited only by our imagination and ability to code they can be adapted to fill any gap we have to fill.

Using VI server the same Ae can be accesses across application and over the network if the app grows and spreads.

So be developing using AE's instead of globals we don't have to go back and replace the globals with AE when the customer says "Good, now we want to do the same thing but...".

Trying to help,

Ben

[Mark_Yedinak]

---

@Jed Davidow wrote:

HI Mark,

To me, when I hear people say "I never use this because of the potential for misuase" I think that it's like saying "I never use C because it's possible to write data beyond the end of an allocated array and blow everything up".

Like any other tool, I believe there is a right way and a wrong way to use global variables.  IMHO, making a principled choice to *never* use them, even when they are appropriate and convenient just reduces the tools you have available and needlessly increases the complexity of the code.

---

I don't use them because of potential abuse but rather because they are a very poor design choice. Globals don't allow you to have any control over your system. By definition any part of your system can access them. This includes modifying the data. If you can't control how and when something is used you open yourself up to all kinds of problems down the line that are very difficult to fix. By making the system modular with well defined interfaces between modules you can control access to data. In addition, globals tightly couple parts of your system together. You may think you have everything safeguarded but along comes the next developer who uses it in ways you didn't intend and then your whole system goes to hell. They are simply a very poor and bad design choice. Years of experience have taught me to use the tools that work well and provide the least amount of risk to my system. Globals do not fall into that category in any sense of the way. Therefore, they are not in my tool box.

[Jed_Davidow]

I know and understand all these arguments (had to look up your term for Action Engine- I like that better than Functional Global, by the way.  Niiiiice.).

I agree that scalability should definitely be taken into account.  But that has to be considered in light of the total amount of additional work it takes to implement them.

But the nature of most of the work I do (typically small apps developed quickly) doesn't lend itself to that method in every project.

There would be a lot of extra work to use AE's for all of these:

• Creating the AE (It's not a lot of work to copy it form a template, I got it)
• Customizing icon if you want a visual style
• I supoose the default is READ, but you would need to add an enum/string with all write operations
• Combining several discreet items into a cluster to cut down on the number of AEs doesn't seem like a good idea, unless they need to be updated as a unit

As for this specific applicaiton (and this is almost exclusively where I use them), I like them for my configuration...

1) I use the OpenG Write Panel to Config and Read Panel from Config to populate/save the configuration.

2) Depending on the complexity and nature of the code, I will use a sub-panel to embed the global panel in the app.  This allows the user to directly change the settings (Works great in simple situations, not great when the code has to be interactive here or contain code-assisted elements (tables, trees)).

3) A VI-panel could be used, yes (and this would allow for more complex interaction).  But accessing each of those values would require another level of code.

Anyway, this approach works great for small apps that won't be scaled up and that have simple configurations (COM ports, destination folders, scalar settings, etc).  There's almost no coding necessary to integrate it into the GUI and have it save and load when required.  Granted, the user can change the globals directly when they wish- but you just don't use this for values where that can be a problem.  I also latch these values into private data when necessary.

This makes for quick development in simple apps.  I don't see how this has potential for memory issues (a handful for scalar values should not be a problem).  Race conditions CAN be a problem, but I seldom run into that with this system.  And yes, there is a loss of scalability, but that has to be weighed against development time and the nature of the product.

My whole point is that you are right about eveything that you posted, but that doesn't mean that there aren't perfectly valid and useful places for global variables.