I finally figured out a bug in my VFP code that we use to add data to custom fields in QuickBooks invoices!!!!
Well, actually, it turns out that there was no a bug in *my* code at all… The bug (so to say) was in the qbfc.h constants file that I had used successfully for years to do this very task. However, apparently when I upgraded to QuickBooks 8.0, the Enumeration values for the various QuickBooks object types changed from what they were in the previous version, for which my qbfc.h file had worked just fine.
When programming QuicjkBooks with the QuickBooks SDK, you use various constants to describe what objects, actions, or transactions you want to create or edit. So, the best way to deal with this pattern in programming languages is to assign Enums for each value, which makes your code much easier to read, and modify; you see words rather than numbers, and, should the Enum values change, your code that uses the Enums will still work. However, it *is* important/necessary to update the Enum values to match the API of whatever you are programming against. Duh! So, in C#, the Enums and values live in a namespace and a dll file that you get with the SDK. But, In FoxPro, you have to build your own .h file to define and manage “constants”, which are basically used in the same way as Enums in C#.
The original qbfc.h file that I have came from a guy named Cris Musgrave. I found it somewhere on the internet several years ago. (Thanks, Cris.) The file had dozens of constant names and values assigned. I sure wish I new where Cris got these values, as it appears to be generated from some other source. Surely, he did not type in all the values himself! Also, it was from 2004, and work great with QB 2004, and so on, until I got to QB8.0. That’s when it quit (a couple of years ago, and I just now got motivated to find the problem!) I’ve tried to find out how to reach him, but I’ve had no luck. (Hey, Cris, give me a shout some time, please.)
So, it turns out the problem was simply that the constants from the qbfc.h file no longer match the integer values for QB8.0. Easy to fix, if I just can learn what the new values are. Well, I’ve looked all of the Google, and I cannot find such info. If you know where to find this valuable info, please let me know.
Here’s the VFP code that sets the object type when you are goinf to add/modify a custom data field on an existing invoice:
So, in the above method call, the “tdetInvoice” is a reference to a constant value from the qbfc.h file, which was defined as 11, but as of QB8.0, I’ve learned that the actual value for the “tdetInvoice” object is 13!!! (See below to learn how I figured this out.) Obviously, I can now see that these values are subject to change with any given release of QuickBooks, so watch out. I sure will.
Here’s a peek at the qbfc.h file I use with FoxPro:
In fact, I’ll bet many/most of the values are now wrong when used with QB8.0. I need the correct values!!!
Here’s how I figured out that the correct value for the constant/Enum “tdetInvoice”:
I downloaded a sample C# app a QBFC sample from the Intuit web site, and I opened the Solution file in Visual Studio. I could see in the references that it includes a reference to QBFC10.dll, so I used the Object Browser to peek inside the QBFC10.dll assembly to see the namespaces and Enum classes, and after some snooping around, I found the golden info that I needed:
Then, I wrote a line of code to see what value I got when I referenced this constant:
And, the Watch window in Visual studio will show you the value of a variable:
So, this is a long, slow process, but I have now corrected my qbfc.h file, and my code is working again!!! I suspect there are other changes to, but I only use a small set of them, so, for now, my code works fine. I’d love to know how to extract all the Enum names and values from a dll so I could generate a full, accurate qbfc.f file. Anyone know how to do this?
7 thoughts on “Adding custom data to QuickBooks invoices from FoxPro”
Likely the way Cris created it, and the way you can update it, is using the VFP Object Browser. If you open the type library in the Object Browser, find the Constants node, and drag it to a PRG or .H file, it’ll generate the #DEFINE constants for you. Same thing with Enums, although you need to drag each enum rather than the Enums node.
Wow, I just made the code changes from that link I pointed you to (http://www.dbmonster.com/Uwe/Forum.aspx/foxpro/7047/Utility-to-extract-print-all-enumerations) so the Object Browser will have full drag-and-drop support of the entire Enum node. Plus, is adds a comment for each node name.
Here is a sample of the the results, nicely formatted, and again, all from one simple drag-and-drop!!!
*— Constant Group: ENOpenMode
#DEFINE omSingleUser 0
#DEFINE omMultiUser 1
#DEFINE omDontCare 2
*— Constant Group: ENRqOnError
#DEFINE roeStop 0
#DEFINE roeContinue 1
#DEFINE roeRollback 2
*— Constant Group: ENReleaseLevel
#DEFINE rlPreAlpha 0
#DEFINE rlAlpha 1
#DEFINE rlBeta 2
#DEFINE rlRelease 3
Thanks for this tip Doug.
It led me to this helpful thread I found about using the Object Browser to extract Enum values, as you suggested.
There’s lots of good discussion in this thread about the issue, including code changes to make in the object browser source code from xsource to make this work better.
The bottom line is, even without making any code changes, you can actually drag and drop the “Constants” node and it will give you *ALL* the Enums, which saves you from dropping each Enum node separately.
Update… 2011-02-24: Problem solved in a better way!!
See this post: http://mattslay.com/extracting-enum-values-from-an-assembly-file-using-the-object-browser-in-foxpro/
Are you using VFP9 and QBFC10?
I’ve had an app running VFP6 with QBFC6 for years with no problem. I updated the app to VFP9 SP2 and now QBSession.OpenConnection() returns .NULL. with no error.
Any idea what I should be looking for?
Yes, I am using VF9 and QBFC10. Here the code that creates the Session Manager object that I use:
loSessionManager = CreateObject(“QBFC10.QBSessionManager”)
Here’s a thought – Have you configured QB to allow access of the new app? You know that in order for an app to access the QB datafile, to must have QM open in admin mode the first time you access the company file with the app, and QB will then ask you if you wish to allow access to the app. My guess is that QB allows your old VFP6 app to access the file, but it sees the new app as a different one, and is denying access until you allow it. This is done to protect your QB data from just being accessed by any old app that want to. Might this be your issue?
If you send me more of your code, I’ll be glad to review it and see if I notice anything different from the way mine works. Email to: firstname.lastname@example.org