Office 2010 apps crashing when VBA is accessing VFP DLLs

[chriscrowhurst]

Hi,

My organisation is upgrading to Office 2010 soon. I am currently testing out some of our customisations made in some VBA apps. Several of these VBA apps both Word and Excel are crashing whenever they are accessing some DLLs written in VFP. The CreateObject call works fine, but as soon as I access any properties, BOOM!
For example :

Public Sub Test()
Dim o As MyVFPDLL.MyClass
Set o = CreateObject("MyVFPDLL.MyClass")
o.DatabaseUserName = "CHRISC" <----- CRASHES HERE
Set o = Nothing
End Sub

When the Office app crashes I get the standard "Microsoft Excel has stopped working" error, then it restarts again, but gives no indication of what has gone wrong. I have tried Windows 8.1 and 7.

This problem so far seems to only affect VFP calls. I tried some testings calling ADODB.Connection and ADODB.RecordSet and they are working fine.

Has anyone experienced this problem before and got any suggestions on how to fix it ?

 

[Dan Freeman]

The first thing I'd check is to make sure the requisite VFP runtime is properly installed and registered.

Other than this, "<----- CRASHES HERE" isn't a lot to go on. Is there any error message? Anything in the Windows event log?

 

[GriffMG]

Dan is right, you need the runtime files from the correct version(s) of VFP

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[chriscrowhurst]

This is what is happening at the <----- CRASHES HERE stage, this is all I have to go on at the moment:
"When the Office app crashes I get the standard "Microsoft Excel has stopped working" error, then it restarts again, but gives no indication of what has gone wrong."

This is happening my dev machine which has VFP7 , and 9 installed. All our workstations have VFP7 runtimes installed.

I have just looked in the event log and have the following application error.
Faulting application name: WINWORD.EXE, version: 14.0.7134.5000, time stamp: 0x541c2dcc
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x029964e2
Faulting process ID: 0x610
Faulting application start time: 0x01d0da54b7171aa8
Faulting application path: C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE
Faulting module path: unknown
Report ID: 2467ebd5-4648-11e5-bedc-4c72b9130d07
Faulting package full name:
Faulting package-relative application ID:

After this is a Windows Error Reporting error containing :

Fault bucket 50, type 5
Event Name: BEX
Response: Not available
Cab Id: 0

Problem signature:
P1: WINWORD.EXE
P2: 14.0.7134.5000
P3: 541c2dcc
P4: unknown
P5: 0.0.0.0
P6: 00000000
P7: 029964e2
P8: c0000005
P9: 00000008
P10:

Attached files:
C:\Users\xxx\AppData\Local\Temp\76922174.cvr
C:\Users\xxx\AppData\Local\Temp\CVR85E9.tmp.cvr
C:\Users\xxx\AppData\Local\Temp\WERBED3.tmp.WERInternalMetadata.xml

These files may be available here:
C:\Users\xxx\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_WINWORD.EXE_b94d181afda7ed2bdda1ec29c5cfb0efb3b1b0_057dda5f

Analysis symbol:
Rechecking for solution: 0
Report ID: 2467ebd5-4648-11e5-bedc-4c72b9130d07
Report Status: 0
Hashed bucket: 435af8cb94cf26ca71139eeb81698386

 

[chriscrowhurst]

As a side note these VBA apps where working perfectly fine in Office 2007.

 

[Olaf Doschke]

First of all there is an interesting observation that the error message talks about Excel failing and your event log is about WINWORD.EXE. Are you sure you look at the right entries?

Another approach: Your OLE class has to be a custom or session or any native VFP base class and all of them support an Error Event.
COM clients won't see the VFP error happening, unless you use COMRETURNERROR().

So add an Error() event to your VFP olepublic class, recompile and reregister it:

Procedure Error()
      Lparameters nError, cMethod, nLine

      Comreturnerror(_vfp.ServerName,'VFP Error No:'+Str(nError,5)+' Line:'+Str(nLine,6)+' Method:'+cMethod+' Message:'+Message())
Endproc

Good Luck getting more info from the error event.

Bye, Olaf.

 

[chriscrowhurst]

Hi Olaf,

I have just tried another example in Word to trigger the error, so that I could check the event logs as per Dan's suggestion. I have also built a small test DLL that looks like this :

Define Class emstest As Custom OlePublic

Function TestMessage(tcMessage As String) As Boolean Helpstring "Returns a test message"
Return tcMessage
EndFunc

EndDefine

I will add your error event to this and see what happens.

Cheers

Chris

 

[chriscrowhurst]

I have just tried installing Office 2010 and VFP7 on a clean install of Windows 10, creating a test DLL as in the above post, and calling it from VBA code in Office 2010 and I am getting the same program crash errors.

Can someone confirm if they are able to successfully call a VFP DLL via Office 2010?

Thanks for your help!

 

[Olaf Doschke]

I fear you don't find many with old VFP AND old Office.

I can start a VFP9 SP2 ole class from a DLL within a Word 2013 VBA Macro on Windows 8.1 and set a property of it, doing:

Dim var as Object
Set var = CreateObject("myole.classname")
var.property= "test"
MsgBox(var.property)

Doesn't matter, if Single Threaded DLL or Multithreaded.

Bye, Olaf.

 

[Olaf Doschke]

If I do Dim var as myole.classname I get a VBA compile error: User-defined type not defined.

I'm not at all into add-ins and registering typelibs in VBA, but if your registration was done with an outdated typelib you may get errors on properties, which have changed or were added since first OLE class registration in VB, which I think is separate from the registry registration of an OLE class.

While this is happening at the DIM line for me, if you had registered a COM class without the property you now make use of, that would explain an error because the typelib VBA knows of doesn't have that property yet.
Just a thought - I am no expert in VBA and OLE usage within it. I actually don't find where to add the userdefined type.

Bye, Olaf.

 

[chriscrowhurst]

Hi Olaf,

Genius! Your thoughts gave me an idea. I have recompiled my DLLs using VFP9 instead of VFP7 and now they are working fine under Office 2010. So the only thing I need to do now is update all our workstations to include the VFP9 runtime when we roll out Office 2010.

Thank you for your thoughts and help.

Regards

Chris

 

[Olaf Doschke]

Glad it gave you that spark of an idea. I don't know what changed between VFP7 and 9 in regard to COM, though. I have in mind the last essential changes were indeed in VFP7, introducing DCOM capabilites aka COM+, I don't see a later change in COM functionality. Beware, that some changes in SQL behaviour might hit you, you may SET ENGINEBEHAVIOR 70 to have VFP7 compatible SQL query behaviour. The better choice is to change SQLs with GROUP BY, but maybe that's even not in your COM classes, anyway. If you do queries, ENGINEBAHVIOR is a quick fix without needing to go through all queries and adapt them. It also does not hinder you to do things like more joins or subqueries in places VFP7 didn't supported them.

In the meantime I found a place in the VBA window in Tools->References. I can check and add my VFP DLL typelib there, but still DIM As specific ole class does not work out on Win7, only on Win8.1. Strange.

Bye, Olaf.