I’ve blogged before about converting my FoxPro apps from application forms to the Business Object based programming approach (thereby moving away from forms based heavily on open tables, work areas, and relations). I used the West Wind wwBusiness classes to make this transformation, and it is the most exciting VFP work I have ever done. A Business Object framework like West Wind wwBusiness automatically gives you basic niceties such as methods like Load() and Save() right there on the BO to do all the back end data handling for you. This feature alone allowed me to greatly reduce the amount of code I had piled up in click events all over my *forms* for many years. No more worrying about the the record pointers, or relations, or binding my form UI controls directly to table names and fields. I promise you, once you go BO’s you’ll never go Back!  (Don’t get sidetracked from this post yet, but you can read my original review of the West Wind wwBusiness library here.

Another benefit of BO classes is that you can now programmatically drive your application’s activities by making method calls into the various methods on the BO. No UI forms required… Just good old procedural code! For instance, on my Job Business Object, I have lots of methods to fetch records into a local cursor, array, or collection, as well as other methods that change or examine data on the BO, or return scalar values, etc.  I started out forcing myself to  test my BO’s from the command line to make sure I could manually orchestrate everything I wanted my forms to do. This would ensure that it would require very little code in the UI forms to make the app work. With all the essential code tucked away in methods on BO classes you can then basically create the same app in SCX Forms, or web frameworks, or just good old procedural programming in various PRGs. Plus, the ease of maintenance improves greatly, since all your code lives in one class, rather that splashed all over the place inside a form.

So I’ve had this vision, after hearing more and more about all this “Test First” buzz in other coding circles like .Net and Rails, that I could write a suite of PRGs that serve as tests I can run at any time on my entire collection of BO’s. This allows me to immediately test every BO in my library any time I make code changes anywhere in the class hierarchy, or even if the table schemas changed too. I can’t tell you how many times I’ve made low level changes in the base classes, or added a new top level method to a concrete class, or changed a field name in a table, and the only real way I’ve had to test the changes is to throw out a beta version of the app, and drive it around like a real user to see if it works correctly, or has errors.

Here is a peek at one of my Business Objects; the “Job” Business Object which is a vital part of many forms in my app. There are perhaps 20 or more granular methods that can be called to do all kinds of fancy stuff on a Job in our system. Every method  can be called directly from the Command Window, or from methods in forms, or from within PRGs. Just create an instance of the Job object, and off you go. Most of this code once lived in a SCX form somewhere, until I pulled it all out and put it in this Job Business Object.

And shown below is a sample of the test code I have written which creates a Job Business Object, and then tests a particular method (the GetActiveJobs() method in this example). You’ll see in the comment that this method can accept up to 5 parameters, so I’ve written tests for many possible combinations of parameters and values. Even with this many test calls, I’m sure there are a few combinations that I may have missed. This shows how tedious a full test suite can become. In this testing approach, you basically *TRY* to break your code by passing in every possible combination of parameters that these business classes might see in real application usage. Remember, you want to write these classes with the idea that you or someone on your team will be working with these classes for years, you simply expect them to work without knowing all the do’s and don’ts about calling into these methods.

What you don’t see here is that the test method calls likes BeginningOfTest(), TestProgress(), and EndOfTest(), record logging info to a results file that I can then review to study the return values, processing time, etc.

Now, the bad thing is that if I complete this exercise, there are perhaps 20 or more methods that I must write tests for, and that’s just on the Job Business Object. Then I’ll have to tackle all the other Business Objects in my libraries (PurchaseOrder object, Quote object, Part object, etc. About 15 Business Objects in all). So this is no trivial amount of work, and you have to remember to write a test for every new method you add to a Business Object, otherwise, you’re letting the thing fall apart. It’s very easy to look at your code and think you’ve got everything or every situation covered, but certainly creating a formal test suite for your classes will help identify problems before you take your app to production. Oh, you’ll also notice that CreateWWBO() is a factory method that returns a Business Object based on the passed key, so there’s some other coding in my architecture that resolves this tag and the class name as well as the class library.

And here is the output to the log file. If there were any errors returned from the Business Object, or if the return results were not the expected results, then I’d see reporting to this effect in the log file. Now, there is some coupling here between these tests and test data that I’m running against, so the test could appear to break if some of the test data changed, so this is no magical solution and requires some attention to this detail when preparing and running these tests. To me, the main effort is to find broken code in the classes given a predictable data set.

This is just one code sample. I have other tests that test the basic Load(), New(), Save(), and Delete() methods as well.

By the way, you can read my original review of the West Wind wwBusiness library here

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:

loDataExtMod.ORListTxn.TxnDataExt.TxnDataExtType.Setvalue(tdetInvoice)

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!!!

Problem Solved

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?

An “object explorer” or “object inspector” is a visual tool that provides a GUI mechanism to explore and navigate the hierarchy of a saturated FoxPro object. This allows you to see all the property names and values that live on an object, and any nested hierarchy that is often present on complex objects like Business Objects.

In my studies of this type of tool, I have come across three available choices. If you know more, please leave a comment, and I’ll add them to the article so that we can have a complete list.

Three tools are reviewed in this article:

• Mike Feltmans’ Collection Explorer
• CodeMine Object Explorer
• Tamar Granor’s Object Inspector (coming soon)

Mike Feltman’s Collection Explorer

At SWFox 2008, I saw Mike Feltman present a session on FoxPro Collections, and in that session he briefly showed what he appeared to regard as an incidental tool he had developed, which he called “Collection Explorer”. Even though it has “Collection” in the name, it actually works on ANY FoxPro object, so I quickly used this tool to take a peek at one of my relatively complex West Wind wwBusiness business objects:

I became really interested in this tool, and instantly added it to my FoxPro IDE toolbox (after bugging Mike for a few weeks to release the final version which he promised in his session). I even integrated it into my production app as a way to allow advanced users to dig around in ways that were not provided in the main forms of my app.

CodeMine Object Inspector

In my typical fashion, I also began to dig around and stir the pot in the community about this problem space, and somehow that lead me to another tool called the CodeMine Object Inspector.  You can download it from here: http://www.codemine.com/ (under the Free Developer Tools). The source files are dated 1999, which is kind of old, but it seemed to work fine in my initial tests in VFP 9 SP2.  Here is a screenshot:

I have not used it extensively, but at first glance, it seems to cover all the basics that the other tools do.

Tamar Granor’s Object Inspector

Sadly, I did not attend the SWFox 2010 conference after having made my first SWFox conference in 2008, and again in 2009. I first heard about Tamar’s Object Inspector from Jim Nelson, the author of PEM Editor on VFPx, who was at the 2010 conference. We spoke daily during the conference so I was able to keep close tabs on everything.  One of the updates he gave me was that Tamar Granor made reference to an “Object Explorer” tool that she was developing. Following the conference I asked her about it on UT, and sure enough, I eventually saw it for the first time in November 2010. In mid-December 2010 she released a second iteration to a small group for testing and feedback. 

There will be an article on the Object Inspector in the January 2011 edition of FoxRockX.

Release plans: She has stated that her plan is to submit the Object Inspector to VFPx. I don’t know what her expected timeline for release is, but I’ll keep you updated as I know more about it.

Here is a screenshot:

I want to share some code from my custom grid class that creates an easy way to programmatically bind columns in a grid to a cursor that is opened in the workspace. Basically, this method binds each column’s ControlSource property to the field in the cursor that you specify. It  also handles calculated fields, Casting, and a few more things I’ll show in the code samples below.

You do have a custom grid class that you use in your apps, right? So, now just do two things to your grid class:

• Create a new placeholder method on your grid class named SetColumnControlSources().
• Create a new method named BindColumn() and add my code from the BindColumn() code sample below.

Now, in each instance of the grid that you use on a form or class or subclass, create the required columns on the grid and set the header captions to match what you intend to show in the grid from the cursor. Be sure to give each column a smart Name property for easy coding (see example below). You do not set the ControlSource of each column while designing the grid. That’s what my fancy BindColumn() method does for you, along with a few more things you’ll see in the code sample. You will make calls to the BindColumn() method from your SetColumnControlSources() method to do the real work. I’ll show you how…

In the SetColumnControlSources() method of each grid instance, you’ll write code like this (specific to each grid<—>cursor matching that you want to build):

Sample SetColumnControlSources() method code:

Local lcRecordSource

With this
.BindColumn(.colItem, ‘item’)
.BindColumn(.colPrint, ‘print’)
.BindColumn(.colPartNo, ‘part_no’)
.BindColumn(.colAltPartNo, ‘altpartno’)
.BindColumn(.colDwgNo, ‘dwg_no’)
.BindColumn(.colDesc, ‘desc’)
.BindColumn(.colQty, ‘qty’)
.BindColumn(.colPrice, ‘price’)
.BindColumn(.colTotal, ‘qty * _RecordSource.price’)
.BindColumn(.colLaborCost, ‘laborcost’)
.BindColumn(.colLaborHrs, ‘laborhrs’)
.BindColumn(.colMachRate, ‘laborcost / _RecordSource.laborhrs’, ‘N(10,2)’)
.BindColumn(.colMtlCost, ‘mtlcost’)
.BindColumn(.colMtlMarkup, ‘mtlmarkup’)
.BindColumn(.colPartCost, ‘laborcost + _RecordSource.mtlcost + _RecordSource.mtlmarkup’)
.BindColumn(.colTotalCost, ‘qty * (_RecordSource.laborcost + _RecordSource.mtlcost + _RecordSource.mtlmarkup)’)
EndWith

*– Other fancy stuff you can do in addition to the above —

lcRecordSource = this.RecordSource

If !Empty(this.RecordSource)
this.colItem.DynamicFontUnderline = ‘iif(‘ + lcRecordSource + ‘.divider=.t., .t., .f.)’
this.colprice.DynamicCurrentControl = ‘iif(‘ + lcRecordSource + ‘.no_quote, [lblNoQuote], [Text1])’
EndIf

Notice how we can build calculated columns that are not even in the cursor, and easily setup a Cast() to control decimals and some DynamicXXX formatting too. Plus, it gives me one nice code window to see all my column binding without having to use the Property Sheet to see what each column is bound to.

So the above is *your* code, and now here’s *my* custom BindColumn() method code that you need to add to your grid class to handle the code you’ll write like the above. This methods assigns the Column.ControlSource property, expanding any _RecordSource references, and also handles the optional Cast() function (see code for .colMachRate above to see how to specify a Cast() format in the third parameter of the BindColumn method).

BindColumn() method code:

Procedure BindColumn()  (Add this method to your grid class)

Lparameters toColumn, tcBindExpression, tcCast

Local lcFieldExpression, lcBindExpression, lcRecordsource

If Vartype(toColumn) = ‘O’ and Upper(toColumn.baseclass) = ‘COLUMN’
lcRecordsource = toColumn.parent.RecordSource

If !Empty(lcRecordsource) and !Empty(tcBindExpression)
  lcFieldExpression = Alltrim(Strtran(Upper(tcBindExpression), ‘_RECORDSOURCE’, lcRecordSource))

  *– Combine RecordSource.FieldExpressiopn
  lcBindExpression = lcRecordSource + ‘.’ + lcFieldExpression

  *– Wrap in Cast() statement if casting was passed in
  If Vartype(tcCast) = ‘C’
   lcBindExpression = ‘Cast(‘ + lcBindExpression + ‘ as ‘ + tcCast + ‘)’
  EndIf

  *– Finally, set controlsource on column…
  toColumn.ControlSource = lcBindExpression
EndIf

Else

Return

EndIf

Finally, to make it all work, you simply set the RecordSource property on the grid and then call SetColumnControlSources():

thisform.Grid1.RecordSource = ‘csrDataCursor’

thisform.Grid1.SetColumnControSources()

I found having this in place to be an effective way to handle times when I need to kill the cursor, rebuild it, and then re-bind to it.

Like this:

thisform.Grid1.RecordSource = ‘’

*—Now rebuild the cursor

thisform.Grid1.RecordSource = ‘csrDataCursor’

thisform.Grid1.SetColumnControSources()

So there you go. Several tricks could be used to pass in the cursor field that you want to bind to.  I’ve also thought about including a provision for passing in the Header caption too.

Enjoy, revise, and post comments to share any other ideas you have for extending this.

I’m not really sure why I’m so driven to do this, but I’ve always been a spread-the-news kind of guy for the VFP community. Any time I see something cool, or that I think others may be interest in, I make a post here-and-there to all the most popular FoxPro sites to spread the word.  So, about a month ago I cranked up this blog for the purpose of doing just that, thinking this would be a good way to go.  Now, I don’t want to compete with the existing forums, because it’s easy enough to go there and make announcements, but I have to visit UniversalThread, and  Foxite, and the ProFox and VFUG lists too, oh, and even Fox.Wikis.com, oh, and sometimes use my FoxCentral.net account. I usually have to hit all those sites with a bunch of cut-and-paste to work all the places I want to reach. Plus, after posting to forums and lists, if I need to tweak the info (corrections, add details, etc), it’s too late to edit or just too much work. And, any conversations (comments) about the topic are now spread out across all the different places and there’s no one place other readers can visit to take it all in. Plus, the formatting and image posting in a blog is much better.

So, I’m trying to decide whether it really adds any value to put this info in a blog post and try to get an audience following the blog, or just keep it old school and post in multiple places.

Your opinions please.