I'm getting an error trying to instantiate Intuit QBFC16 in VFP.

qbfc = CREATEOBJECT("QBFC16.QBSessionManager.1") 

will fail with OLE error code 0x80040154: Class not registered

I'm thinking the issue is that QBFC16 is 64-bit so VFP can't instantiate the interface. If that's the case, is there an easy way to call it from VFP 9?

I think we could build a .net assembly wrapper around QBFC16 that exposes the needed methods and structures, and then call it via wwDotnetBridge. I'd prefer not to add that complexity if there's another way to get it working.

The QBFC is part of the Quickbooks SDK, and provides a COM interface to Quickbooks. The Quickbooks SDK was ported to 64-bit as of Quickbooks 2022. I believe the QBFC also became 64-bit at at that time, which was version QBFC15. Quickbooks versions prior to 2022 were 32-bit and the QBFC was 32-bit, up to QBFC14

VFP 9 is able to instantiate a QBFC13 instance, using createobject. For example, this works:

qbfc = CREATEOBJECT("QBFC13.QBSessionManager.1")

However, if you install QBFC16, the latest version as of 4/27/2023, this will not work:

qbfc = CREATEOBJECT("QBFC16.QBSessionManager.1") 

fails with OLE error code 0x80040154: Class not registered

I can confirm QBFC16 is installed and available by creating an instance in PowerShell:

$qbfc = New-Object -ComObject QBFC16.QBSessionManager.1
$qbfc | Get-Member

Note the difference in paths for QBFC 13 and 16. 16 is in the 64-bit path and 13 is in 32-bit path:

QBFC16 is installed to C:\Program Files\Common Files\Intuit\QuickBooks\QBFC16.dll
QBFC13 is installed to C:\Program Files (x86)\Common Files\Intuit\QuickBooks\QBFC13.dll

If the SDK is 64 bit and InProcess, then you won't be able to call the SDK from FoxPro directly.

There are a few options you can try:

• Use VFP Advanced which can run in 64-bit (but in turn can't call 32 bit DLLs)
• Build a separete EXE that you can automate in another language like .NET and then call that from FoxPro to perform your 64 bit tasks.

+++ Rick ---

Thanks, I assume it's in-process so that's the issue.

Oddly enough, same error in VFPA:

But I can instantiate it in Powershell 64bit so I know it's registered correctly. At this point, if we decide to support Quickbooks 2022 & 2023 we'll write a .net assembly to serve as an interface using dotnetbridge, or something like that.

I was wondering if there was a easy way to tell if a DLL loads in-process or out-of-process? At this point, it's academic, but I've never needed to know for an arbitrary DLL before.

Make sure you're running the 64 bit version of VFPA.

Take a look at Process Explorer and see what it shows for the EXE for the Bitness.

+++ Rick ---

It won't work with wwDotnetBridge, because that's 32 bit too and still InProcess. .NET natively doesn't support building out of process COM (DCOM) servers unfortunately. It can be done but all that interface stuff has to be set up manually which is a lot of work and easy to screw up. I tried at some point and gave up 😄 - and ended up just using a plain EXE with parameters and results dumped into a file.

To do this you need to do is create a .NET (or anything that can produce a 64 bit standalone executable) exe and then communicate interprocess.

+++ Rick ---

Thanks, it was the 32bit bit version of VFPA. Once I made sure to run the 64bit edition it could instantiate the 64bit COM object.

Makes sense that wwDotnetBridge is 32bit.

BTW, I used memory mapped files for inter-process communication on Windows a long time ago with Borland C++. They're fairly easy to use with no dependencies other than Windows.

https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files

https://github.com/jeffpar/kbarchive/tree/master/kb/188/Q188535

Yup. Personally I'm wary of VPA because of licensing potential for unintended bugs that are due to the updates and the mere fact that for most things there's no benefit of 64 bit. More likely 64 bit will cause more issues than it solves - if you depend on any third party ActiveX controls or even the built in ones, or use 32 bit any other library dependencies (like wwIPstuff.dll or wwDotnetBridge.dll for example) - those don't work in 64 bit.

I think the better option is to use some sort of cross-process communication (Named Pipes, Memory Mapped files, plain message files or database records in a message table) or - if the job is simple enough, simply call the EXE and capture the Console output with a 64 bit application like .NET or Node etc.