VBA code works in XP 32 bit, fails in Win 7 64 bit

[jepaff]

Hello from a nubie,

I have a piece of code, written in 1996 and modified slightly through the years.

Sub Main()  ' in form #1, mouseclick on button brings up form #2, 
       Dim btest as Boolean
       btest = CheckWinWedge
End Sub
'  To be clear, I've removed all the other code, leaving just the offending portion. 

Function CheckWinWedge() As Boolean ' in form #2, mouseclick on button check for running program...
    Dim i                 As Integer

    i = 3
    sbWaitaSec i
    ' waited three seconds, return true
    CheckWinWedge = True
End Function

Public Sub sbWaitaSec(iDelta As Integer)
  Dim Nsec              As Single
  Dim iMsgBoxDebug      As Integer
  Dim iDl               As Long
  
  iDl = iDelta
  Nsec = DateAdd("s", iDl, Time)
  Do Until Time >= Nsec
  Loop

End Sub

I have removed all of the miscellaneous, including various error trapping statements. Very consistent failure at the "sbwaitasec" subroutine call.
"Execution of this application has stopped due to a run-time error."

Code works fine on my Win Xp 32 box, fails 100% of the time on Win 7 64 bit.
The win 7 64 bit machine is also using an access runtime (2002 runtime).
Code has worked fine for ~ 15 years in Win 95, 98, XP on 16 and 32 bit machines.

This is a rewrite of code as in 1996 I used something other than dateadd.
Point of code in the program is to give me a short delay while a second piece of softare opens (I know there are other approaches, but 1-2 seconds has been very robust -- and I use 3 -- and can then be checked without going into an infinite loop.)

Specifics: Main is part of form #1, function is part of form #2.
bottom routine is part of a separate module.

all other code, including a shell command before it, are working (validated with multiple "before" and "after" messages. No errors. Some error trapping exists in the real code.)

Main program has had all "kernel32" calls rewritten, as I had an immediate API bug when we first attempted this on the 64 bit machine.

Have tried three calls to subroutine:
Call sbwaitasec(1)
sbWaitasec 1
sbWaitasec(1)

All 3 statements fail on Win 7 (64 bit, runtime only) with the same error message. All work on my machine (full Access, Win XP)

Any thoughts?
Thank you! - John

 

[spikepl]

So what steps have you undertaken to determine what exactly upsets the system inside your sbwaitasec? Or whether it is the call itself?

 

[jepaff]

So what steps have you undertaken to determine what exactly upsets the system inside your sbwaitasec? Or whether it is the call itself?

Because I was receiving the error, I added a first line to the sub, a debug line -- in this case, a msgbox. It never prints the message. Best I can tell, it is the call itself.
Thanks. - JP

 

[spikepl]

I would then deconstruct the issue.

Is it the name of the sub or is it the IiDelta? In your example you don't declare it as Integer in the calling environment but as Variant. Try declaring it as integer.

 

[jepaff]

I would then deconstruct the issue.

Is it the name of the sub or is it the IiDelta? In your example you don't declare it as Integer in the calling environment but as Variant. Try declaring it as integer.

OK thanks. Let me see if I understand what you've said here.

.... calling routine
Dim iSomeInt as Integer '<-- this defines the variable in the calling environment?
' and is missing (variant)

call sbWaitaSec(iSomeInt)

.....
Dim Public sbWaitaSec(Idelta as Integer) '<-- this line, in the example, does not require changes?
'(do something here)
End Sub

I'll insure I have it.
Greatly appreciate your response. - JP

 

[spikepl]

I have no clue what the issues is so I am going for all I can think of. Maybe it's the Variant declaration that should be Integer, or maybe it is the name of the sub - however unlikely. If the Integer declaration doesn't cure it, I'd try to rename the sub into, say, sbWaitaSec2 and see if that helps. Also, you could gut the sub and remove all its contents. If it then works, then add back one line a time.

The last straw to grasp is to compact/repair, decompile, compact/repair.

 

[jepaff]

Re: gutting procedure.
In fact, I've taken all the other lines from everything else, at this point, and left only a bare skeleton to initiate the call with a couple message boxes to define location. Haven't tested it, machine is in use for other items. Will drop feedback here after I test.
- J

 

[jepaff]

Re: gutting procedure.
In fact, I've taken all the other lines from everything else, at this point, and left only a bare skeleton to initiate the call with a couple message boxes to define location. Haven't tested it, machine is in use for other items. Will drop feedback here after I test.
- J

Still no joy in Mudville.
Variable is clearly defined as Integer in main, and as required integer in sub variable list.
Should be no problem.
Still get error -- before anything else happens -- in the subroutine (ie, no line of sub runs.)
Changed name of subroutine using Find - Replace everywhere, no improvement.

I am reasonably convinced the error lies in some combination of Runtime 2002 / Win 7 64 bit DLLs. Code works fine, is simple. We're giving up, and will migrate to consistent & new version in hope that cures it.
- John

 

[spikepl]

DID you gut the procedure? Remove all its contents and re-add if that works? Did you try to decompile? And one other thing that you could try: Copy the module code into a text file, erase all the code, paste the code back from text file. Or even better, erase the module and make a new one and paste the code into that. On some weird occassions (connected to debugging in the cases I have heard of) some invisible garbage can hang onto the code

 

[jepaff]

Yes, took out everything except the call. It is the call itself that is failing. Even removing the variable doesn't make it work.

Did not attempt to decompile. Didn't think about that. Also would be better if the code were created on a 64 bit machine, but I don't have that available.

Appreciate all you thoughts. - JP

 

[boblarson]

Does it do the same if you convert the SUB to a FUNCTION instead?

 

[jepaff]

Does it do the same if you convert the SUB to a FUNCTION instead?

I thought about that, as this was written as a sub only because I don't need a return. No, I didn't test it.

I did run one more test, on the dummy code. took the 64 bit box, unplugged it, put a 32 bit box identically configured (best we can, anyway) and ran it. So, runs fine on (XP) Access 2010, (XP) runtime Access 2002 32 bit, but fails on Win 7 64 bit.

Folks, appreciate all the thoughts. The IT group more-or-less said stop mucking and allow them to either update software or bring the machine back to 32 bit. My suspicion is Access 2002 has a runtime module that is 32 bit that Win 7 is trying to run as 64 bit with the expected result. I dont know how to test that, and will let them fix the machine, more or less, and we'll revisit. Again, thanks for the help and suggestions.
- John

 

[boblarson]

Try it as the function. A function need not return anything. And I've found some issues with Subs where a function worked where a Sub did not.

In fact, I almost use functions exclusively now just because it really matters not in the grand scheme of things.