This may be the case if you use an up-to-date version of Access which just received the RegExp object in it's VBA library but the user's computer do have an older version where this is not the case.
Does it also apply to the Shell object? Then this would make absolutely no sense at all. The code excerpts you posed here show your gbl_SH variable being declared As Object. If the type Object is unknown on any computer, there is something seriously wrong with that installation.
Do you maybe have difference declarations of gbl_SH in different scopes? That would be an explanation why gbl_SH can be set and not set at the same time.
Global variables are generally frowned upon. (Not nearly enough IMO!) You should rather use global functions or properties returning an instance of the desired object. That allows you to ...
a) restore/recreate the instances if for whatever reasons they got destroyed.
b) track when which instance is accessed from where.
You also use On Error Resume Next liberally, which is a very poor practice except when contained within code that is able to handle the results in any probable case.
For now, I suspect this mess is not Microsoft's but rather one of your own making.
It applied to the RegExp object. The FileSystem and Shell variables were declared as objects, so of course they compile properly. Only in use did they crap out.
No, I had exactly one declaration of gbl_SH. That was the whole point of using a global variable - declare it once, instantiate it once and use it everywhere.
Yes, I'm familiar with the diatribes against globals, and I find the arguments against them mostly lacking. This was exactly the sort of situation that globals are intended for - an application-wide reference to single object, intended for the same use everywhere. There is NO argument against globals that makes any sense in such use. Yes, functions and properties allow more functionality, but when you don't need such extra functionality, they only add bloat, and reduce execution speed and clarity. And in this case, I don't even know if they would have helped. If you read the thread, you will see that I had such a test, and it didn't work. The variable was still instantiated, but the object it pointed to stopped functioning. And only partly - it still worked correctly in the immediate window, and it worked correctly when I used an intermediate variable to store the results, rather than moving the result directly to the function name. That is not correct behavior under any circumstances.
I don't know why you assume that I use On Error Resume Next liberally, since I posted exactly one short routine in which I used it exactly once. But yes, in those situations, or in situations where there is no possibility of recovering from an error, but I don't want the app to bomb with an Access error message, I do use it. It is cleaner to test the Err value right afterwards than forcing the code to branch off somewhere to a special error handling routine. But I do also use that, when I judge it is appropriate.
If you can point to something I did wrong, rather than vague criticisms of technique, I will look at it, and if it turns out to be the case, I will post it here. But global variables are a perfectly normal part of programming, documented, accepted and widely used.
