Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Calling QBFC16, 64-bit interface from VFP, 32-bit code 1

Status
Not open for further replies.

Chris V

Programmer
Apr 24, 2023
3
1
0
US
Can we use QBFC16 to make API calls to Quickbooks Desktop 2023? It appears the answer is no, but I wanted to confirm that.

QBFC16 is a 64-bit application, and therefore can't be called from VFP which is 32-bit.

Has anyone had experience integrating VFP with Quickbooks desktop using QBFC? And integrated QBFC15 or QFBC16 into a VFP app?

We've used QBFC for years to interface from VFP to Quickbooks Desktop. Usually the version QBFC13 has worked just fine.

Quickbooks 2022 and later are 64-bit. It appears that you need QBFC15 or later to integrate with Quuckbooks 2022 or later, and as far as I can tell, QBFC15 is 64-bit. Intuit has also released QBFC16, and it appears to be a 64-bit application as well.

We also integrate with Quickbooks Online, but once customer insists on using QB Desktop 2023.


 
Sounds like a job for a bit of VFP Advanced 64bit middleware

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 !good for you.

There is no place like G28 X0 Y0 Z0
 
I have no Quickbooks experience. But all talk is about an SDK to use for automation of Quickbooks. It doesn't tell what kind of SDK. In itself, it just means Software Development Toolkit. I get from the discussion that OLE automation is involved or doable. That's what we know from Office applications.

In Office, the automation servers are built into the Office application EXEs and those automation servers are out-of-process COM servers. And that means they run out of your process in their own process. And that means it doesn't matter whether they are also 32 bit processes or 64 bit processes.

So why don't you simply download and install an SDK version compatible with the version of Quickbook you want to cover and try it, before giving up?

Chriss
 
Right, it sounds like QBFC is being loaded as an inproc COM server. Is there any way to force VFP to load a COM server as out of proc?

For future reference if someone comes across this post:

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, and the QBFC also became 64-bit at at that time (which was the QBFC15 version.) 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") will fail with OLE error code 0x80040154: Class not registered

You 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

Oddly enough, I tried using a VFPA 64-bit, it got the same error using qbfc = CREATEOBJECT("QBFC16.QBSessionManager.1") failed with OLE error code 0x80040154: Class not registered

 
The "Class not registered" error only depends on which part of the registry CREATEOBJECT() looks for, when it decides to look for COM classes, as the class name isn't found among the VFP classes it knows as native base classes or from PRGs and VCXes currently set.

So I guess even VFPA 64 bit is programmed with the 32bit registry in mind, to enable usage of the same 32bit ActiveX controls you used before, too. Or simpler, Chen didn't patch how VFP's runtime uses the registry within the CREATEOBJECT() function.

Whether a server is in process or out-of-process isn't a decision of the code instantiating it. An EXE is started as a new process, and a DLL is loaded into your existing process. An OCX maybe both, I'm not sure, in general, it's also just a type of DLL, though. So in short: It is, what it is. And changing file extension also doesn't change that, it's all in the way it works.

You still have a chance to get this working with VFPA, as Chen might make this possible. Maybe there already is a new SYS() function or setting that allows you to specify which registry VFPA executables look at. Also notice, that even the VFPA 64bit version installs a) the VFP9.exe patched with bugfixes, VFFPA.EXE in 32bit and VFPA.EXE in 64bit version. At least that's what I remember from the youtube video of John Ryan.

I actually don't think VFPA still only accesses the 32bit registry. Was it Griff or Stanlyn, who said they used the 32bit version to enable usage of old ActiveX controls, so the VFPA 64bit version should enable using 64bit ActiveX controls or also 64bit COM servers, no matter if EXE or DLL.

Chriss
 
I don't believe it, but is the installation of the Quickbook SDK only putting files where you said without registering them in the installation process? It would be quite "impolite" of such an SDK setup but maybe done so, because the SDK users = developers should know how to get things working. So something like a built-in hurdle to make you read the manuals...

Chriss
 
No, it's definitely registered as a 64-bit COM server. You can confirm that by instantiating it using Powershell 64bit as I outlined above.

Agreed, I don't know of any tricks to force VFP to load an inproc server as out-of-process.

If we were going to write a wrapper around QBFC16 to be called from VFP 9, we would probably not go with VPFA. It looks like a fine product, but it seems easier to maybe build a .net assembly wrapper around QBFC16 that exposes the needed methods and structures, and then calling it via wwDotnetBridge from west-wind. Not hard to do, but again, it's only one of our customers asking about this so it's not a priority.

> You can confirm QBFC16 is installed and available by creating an instance in PowerShell:
> $qbfc = New-Object -ComObject QBFC16.QBSessionManager.1
> $qbfc | Get-Member

And under Powershell 64bit, you cannot instantiate QBFC13, which makes sense, since it's 32-bit. To start Powershell 32-bit, look for "Powershell (x86)" in the start menu.

 
Of course, yes. I overlooked that.

It still makes me wonder how VFPA 64bit then is truly in the 64 bit world. But I'll do my own experiments with that.

Chriss
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top