Watch on All Procedures & All Modules Never, Ever Works!

[Dal123]

Am I the only person with this problem?

If I put a Watch (with a break, or a change when value changes) on all Procedures & all Modules it never, ever works.

If I refine it to a certain Module, and Procedure it works fine, it picks up when the value changes or vice versa. But never, ever when it's watching all procedures & all modules?

Could the problem be that a global watch would only work on global variables? I've gone defining all variables in all Modules (with many different, procedures) as most articles advise this method, though i don't think it was very practical in my situation.

[LJMetzger]

Could the problem be that a global watch would only work on global variables?

Yes. In addition, once you define the scope for global variables to halt on change (e.g. one procedure or all procedures, or one module, or all modules), modifications to the scope do not seem to take effect. The original scope always seems to be in force.

If you want to change scope, I recommend you close the file, reopen the file, and redefine the watch variable.

I've gone defining all variables in all Modules (with many different, procedures) as most articles advise this method, though i don't think it was very practical in my situation.

Global variables sometimes can not be avoided. Often they are not used because we are too lazy to avoid them, or the workaround is too expensive due to nested procedure calls. One of the problems with global variables that you found, is that once something goes awry, it is often very difficult to find the cause of the problem.

Lewis

[Dal123]

Thanks LJMetzger, I'm quite suprised to hear that a global watch only works on a globally declared variable. As my early amateur perspective of the Watches Window is to be able to see when variables change, outside of other procedures, but this will only work if it's a publicly declared variable.

Why on earth would Microsoft design the Watches Window in this fashion?

[xlnitwit]

Perhaps I have misunderstood the nature of the problem, but why would you need a global watch on a variable that is not itself Public/Global?

[Dal123]

Because xlnitwit as I say in my OP I'm just trying to use the Watches Window for what it was designed for - to see when the value of a variable changes. However when all procedures and all modules is selected it never works!

However if you change the variable to a global variable, it will then work.

I've only done some small tinkering with the Watches Window as I become quickly frustrated with what seems like an overrated debugging tool.

[xlnitwit]

My point was really that you don't need to monitor all modules and procedures unless the variable is public.

[Dal123]

Lol, I see xlnitwit. Originally my intention was to have the variables publicly declared as they're being used as parameters all over the place. Looking back I wish I did this, but most tutorials warn to steer clear of publicly declared varibles when possible. As LJMetzger kindly pointed out sometimes they're unavoidable, and it seems I definitely should've used publicly declared.

Thanks for your input guys, much appreciated as always.

[Dal123]

Actually I wonder if I am that wrong. Say you've got 30 procedures, you share variables in 10 of them. If you want to watch when ever the value changes you have to change it to public variable.

Am I the only one that thinks it's crazy?

[xlnitwit]

If you are sharing variables, they are either public or module level. If you need to monitor a module level one, you only need to monitor that module.

[AB33]

Hi Dale123,
It is not.
Most statically complied language do not have the concept "Global variables" (Yes, you can have utilities variables which can act as a global variables within a class). In most scripting languages, "Global variables" are receipt for bugs and should be avoided if you can. Use local variable and watch it using local window. Breaking your code in to modules using local variables is much more easier to maintain and debug than a code that is littered with Global variables.

Imagine, you have 50k lines of code. How painful is to track a variable which has been used in many lines of code!

[6StringJazzer]

Originally my intention was to have the variables publicly declared as they're being used as parameters all over the place. Looking back I wish I did this, but most tutorials warn to steer clear of publicly declared varibles when possible. As LJMetzger kindly pointed out sometimes they're unavoidable, and it seems I definitely should've used publicly declared.

I am a bit late to this party but wanted to amplify other points that LJMetzger made. Don't forget that he also said, "Often they are not used because we are too lazy to avoid them, or the workaround is too expensive due to nested procedure calls. One of the problems with global variables that you found, is that once something goes awry, it is often very difficult to find the cause of the problem."

In the late 1970s Ed Yourdon wrote a seminal work on structured design that provides a categorization of types of cohesion and coupling. Cohesion is how well pieces of code that are physically together work together to perform a function, and coupling is the degree of dependency that two (or more) pieces of code have on each other. You want loose coupling, to reduce the possibility that a change in one piece of code will unexpectedly affect another piece of code. The loosest (best) form of coupling is passing all data to a sub through its parameters. Using global variables is common data coupling, the second tightest (i.e., second worst) form of coupling. If you have a data element turn up someplace with an unexpected value, but it's a global variable, it is very difficult to trace back where it went bad because it's a free-for-all as far as what code can change it. Also, if you change code in one place, it is likely that you will cause unexpected results somewhere else. A classic example of how this is abused in VBA is using ActiveSheet and Selection to work on sheets and cells. Sheets and cells should almost always be explicitly qualified.

In VBA for Excel, sometimes Public or Global variables seem like a really convenient, easy way to do things, but it's almost always possible to engineer a more reliable, maintainable solution. One example is suppose you display a UserForm, and the user makes a selection from a ListBox, then the form closes. Controls in a UserForm are implicitly Public, so any code can read the selection from the ListBox. But another way to do this is to create a Function in the UserForm module to return the value last selected by the user. That way other modules don't have to know anything about how the user selected a value; the UserForm could change to use a TextBox or a ComboBox and the way the Function is called would never change. A problem here is that the language doesn't provide a way to prevent the ListBox from being directly accessed. You could mitigate that by creating a Class for the UserForm, but this is probably overkill for 99.9% of all VBA applications.