Variable assignment not working. (1 Viewer)

pdanes

Registered User.
Local time
Yesterday, 16:34
Joined
Apr 12, 2011
Messages
242
I have one of the weirdest problems I've seen in a long time - a simple variable assignment is suddenly not working.

My app has a few values in the registry, and deals with them on startup. Simple routine:
Code:
Public Function RegKeyRead$(ByVal RegKey$)
' Reads registry key RegKey, if key doesn't exist, return value is ""
On Error Resume Next
RegKeyRead = gbl_SH.RegRead(RegKey)
On Error GoTo 0
End Function
It has been working for years with not the slightest issue, but in the last few days, it has started failing. This line
Code:
RegKeyRead = gbl_SH.RegRead(RegKey)
has suddenly stopped working, and only on some machines. One last week, another Monday, a third one joined in yesterday and a fourth one just now. When I stop the code and do a print of gbl_SH.RegRead(RegKey) in the immediate window, it shows the value correctly - a short text string. When I manually assign that text string to the value RegKeyRead in the immediate window, the routine continues on and returns that value to the calling code. But that simple assignment in code just doesn't work. After executing that line, RegKeyRead remains an empty string, and naturally, subsequent operations fail, since they rely on that value being retrieved properly.

When I skip over the 'On Error Resume Next' statement, it throws an error - 91, Object variable not set. But it IS set. The immediate window confirms it, by returning False to the command ?gbl_SH Is Nothing. And again, ?gbl_SH.RegRead(RegKey) shows the correct value, properly retrieved from the registry.

I don't even know where to start looking for a solution. gbl_SH.RegRead(RegKey) retrieves and correctly displays the value, but the simple assignment of that value to a text string variable fails.
 
if somehow the reference to the Object is lost, can you "force" re-create the object again:
Code:
Public Function RegKeyRead$(ByVal RegKey$)
' Reads registry key RegKey, if key doesn't exist, return value is ""
On Error Resume Next
' re-create the gbl_SH again before
' calling any of its Method
' 
' put the code here
'
RegKeyRead = gbl_SH.RegRead(RegKey)
On Error GoTo 0
End Function
 
You might be over-focused on this single method call as "the problem." What is the code for gbl_SH? How is it created and exposed? Under what circumstances is RegKeyRead() called? You've only shown the entry point.
 
@MarkK : It simply could be a "WScript.Shell" object.

Code:
CreateObject("WScript.Shell")

@pdanes : In such weird situations I always try to DEcompile the accdb.

Edit:
@RonPaii :
Yes, it seems he has. He wrote:
And again, ?gbl_SH.RegRead(RegKey) shows the correct value, properly retrieved from the registry.
 
if somehow the reference to the Object is lost, can you "force" re-create the object again:
Code:
Public Function RegKeyRead$(ByVal RegKey$)
' Reads registry key RegKey, if key doesn't exist, return value is ""
On Error Resume Next
' re-create the gbl_SH again before
' calling any of its Method
'
' put the code here
'
RegKeyRead = gbl_SH.RegRead(RegKey)
On Error GoTo 0
End Function
I'll try that, although the immediate window shows that the object reference is not lost. But I can try creating it again anyway.
 
You might be over-focused on this single method call as "the problem." What is the code for gbl_SH? How is it created and exposed? Under what circumstances is RegKeyRead() called? You've only shown the entry point.
In a standard module, along with many similar declarations:
Code:
Public gbl_SH As Object
and in a start-up routine, called once when the app loads:
Code:
Set gbl_SH = CreateObject("WScript.Shell")
The function is then called in several places as the app starts, setting up initial conditions.
 
Last edited:
Have you confirmed the RegKey exists on the computers with the problem?
It does. And again, when I put ?gbl_SH.RegRead(RegKey) in the immediate window, it shows the correct value. But that value is not getting copied into the function name variable, and it has just recently started doing this, and not on all machines.
 
@MarkK : It simply could be a "WScript.Shell" object.

Code:
CreateObject("WScript.Shell")

@pdanes : In such weird situations I always try to DEcompile the accdb.

Edit:
@RonPaii :
Yes, it seems he has. He wrote:
Yes, I decompile and C&R regularly. It's generally my first move when something strange starts happening, and always as the last step before publishing a new version of the app.

And yes,
Code:
Set gbl_SH = CreateObject("WScript.Shell")
is the code. Happens exactly once, on app start-up.
 
I don't think it's the problem, but you can try to add the $ to the function assignment or delete it from the function declaration and add "as string"
 
it's not a problem alright. it tells that the return of the function is a string.
that is the old vb declaration and still works.
 
has suddenly stopped working, and only on some machines. One last week, another Monday, a third one joined in yesterday and a fourth one just now.

At your site where this occurs, are users allowed to run Windows updates at will, or are they forced to accept updates on a specific schedule? Because this time-erratic behavior COULD be related to a recent Windows update that affected the scripting .DLL file. Is there a way for you to check that? (I mean that in the sense of "are YOU allowed to check that"?) Check the detailed version number of the WScript library file on an affected machine and an unaffected one.
 
At your site where this occurs, are users allowed to run Windows updates at will, or are they forced to accept updates on a specific schedule? Because this time-erratic behavior COULD be related to a recent Windows update that affected the scripting .DLL file. Is there a way for you to check that? (I mean that in the sense of "are YOU allowed to check that"?) Check the detailed version number of the WScript library file on an affected machine and an unaffected one.
Updates are controlled centrally, as part of the domain. Users have limited privileges, like NOT the ability to install their own software. On my machine, where it still works, the version number on Vbscript.dll is 5.812.10240.16384. On another machine, where it stopped working this morning, it is exactly the same. However, the two file sizes are slightly different, as are the dates last changed. But mine, where it has worked all along, is newer (July 28th), while the problem machine is July 18th. Both 2025, of course. Mine (newer) is smaller, though - 604 KB, while the problem machine has 612 KB.
 
Well, an update, maybe even progress of a sort. Everyone bailed and I had a chance to work on this on a user's machine, where it fails, instead of mine, where it works.

I added a local string variable into the function, and used it as an intermediate.
Code:
x = gbl_SH.RegRead(RegKey)
RegKeyRead = x
and it suddenly works. Completely retarded, but it runs.

However, I now have another issue. At another place, further on in the start sequence, I use regular expressions, and a global pointer to an instance of that. In most places where I use this, I have this:
Code:
If rre Is Nothing Then Set rre = New RegExp
just before the With block that operates the RegExp calls. I do not have the 'On Error Resume Next' command here, because I do not expect any errors. The code bombs with the same error - 91, Object variable not set. And again, checking for rre Is Nothing in the immediate window shows False. But when I insert a new command, Set rre = New RegExp into the code, to generate a new instance, regardless of previous state, it works.

So I suppose I have a fix - give up on globals and simply set these object variables everywhere I need to use them. However, my intention was to set these things once, on start-up, and not have to continually re-create new instances of the same thing. I haven't run any timing tests (yet), so I don't know if this will introduce any significant delays. It seems to me that constantly recreating instances must be slower than having one set initially and then used everywhere, but maybe it's such a small difference that it won't be noticeable to the users. And in any case, slower is better than completely non-functional. But it gives me a rash. This is exactly the sort of voodoo programming that I will likely find somewhere down the road, wonder why I would have done something so idiotic and pointless as to use an intermediate variable for a simple assignment. I will 'clean it up' while I'm doing some other work, it will start crashing again, and I will have no idea why.
 
What you describe seems strange, but out of curiosity does this give the same error?
in your module where you declare you global what if you did something like

Code:
Public glblRRE as RegExp

Public Function getRRE() as RegExp
  if glblRRE is nothing then set glblRRE = new RegExp
  set getRRE = glblRRE
end function

Then use is in your procedures going through the self healing function
Set rre = getRRE
 
What you describe seems strange, but out of curiosity does this give the same error?
in your module where you declare you global what if you did something like

Code:
Public glblRRE as RegExp

Public Function getRRE() as RegExp
  if glblRRE is nothing then set glblRRE = new RegExp
  set getRRE = glblRRE
end function

Then use is in your procedures going through the self healing function
Set rre = getRRE
It throws error 91 when I attempt to access the object, but testing it for Nothing returns false, so the 'reset' never happens. I have that test, If rre Is Nothing Then Set rre = New RegExp in every module that deals with regular expression, and it used to work. But apparently at the same time as my original problem, with trying to read a registry key, this also started happening. In both cases, I set global variables to these objects on start-up, and they suddenly are not working. They are not Nothing, but neither are they functional. I flat do not understand what is happening.
 
Regarding the RegExp problem: Can you open the VBA code window? Find the Object Browser and tell it to search for REGEXP to see if it can tell you what library it is in. Another thread in the forums discusses that the RegExp library suddenly is not appearing after it worked OK for a long time. This thread linked below holds some discussions on that topic:

 
Regarding the RegExp problem: Can you open the VBA code window? Find the Object Browser and tell it to search for REGEXP to see if it can tell you what library it is in. Another thread in the forums discusses that the RegExp library suddenly is not appearing after it worked OK for a long time. This thread linked below holds some discussions on that topic:

I tried removing the RegExp library reference. On my dev machine, that works fine, but it all worked even before that. When I copied that version to one of the machines where this problem code had stopped working, it doesn't run. A compile attempt calls out the line where the global variable is declared as an undefined type. (It's the one with the earlier date one the Vbscript.dll file, although with the exact same version number.)

I've made a copy of the app where I've dusted all the global object variables that refer to scripting objects, like Shell, FileSystem and RegExp. I've kept the explicit library reference, because global or local, such variable declarations don't work on the problem machine without it. Instead of the globals, I have local variables in every routine and I create new objects on every call. That seems to work, although I haven't tested everything - this is a rather large app, and testing all of its functionality takes a very long time. But it does not appear to have made any impact on response speed in the calls I did test, so I suppose I've fixed my problem.

Apparently, something damages the global object references. I have no idea what, and it's difficult to test, since the variable remains alive and referring to something. It just doesn't work, so I would have to put multiple calls to the object as I run through the start-up routine, trying to determine when it stops working. Or maybe it never works in those machines - I just thought of that. It's possible that the global version never works, and I only find it out when I try to use it, considerably later in the start sequence than when it is initialized. I'll try that, maybe tomorrow, but I've had enough of this for one day.

Thank you everyone for the suggestions. MS software rarely misses an opportunity to jack my blood pressure.
 

Users who are viewing this thread

Back
Top Bottom