Here’s a new tool I’ve written for Foxpro to add a cool feature for quickly opening a file by entering part of its filename. It’s a fast heads-down way to navigate files in your Project or the Current Directory. Just type a few characters of the filename and it will begin to filter the list of files based on a partial match. When you see the file you want, just click on it, or use the arrows keys and press enter. You can also filter on basic file types such as SCX, VCX, PRG, and FRX.

Think of it as a quick way that you can tell FoxPro “Hey, I want to open a file… I know part of the filename, but I want you to find it for me.”

For now, you can download it here: Download GoToFile.zip (Note: future updates may be posted on VFPx in the Thor Tool Repository package.)

Please send comments or suggestions to me in the comments area at the bottom of this post.

This tool is just a basic FoxPro form that can be invoked from the command window, added to your custom menu, or invoked by a keyboard macro. However, I recommend invoking it with the new Thor add-in manager for Visual Foxpro. You can learn more about Thor here: Thor add-in manager for Visual FoxPro. Once you have Thor installed in VFP, you can just drop these files into the “Tools” folder and then you will see GoToFile in the tool list where you can easily assign a hotkey to it.

Version control for FoxPro source code

If you want to place your FoxPro source code files in a Source Code Repository of some sort, you usually need to generate text file versions of your table-based FoxPro files like SCX, VCX, and FRX. These text versions of the binary FoxPro files are necessary for the versioning features of code repository tools work properly. FoxPro is unique in having binary source code files in a projects, whereas most other languages use raw text for all of their code files.

We’ve long had a tool to generate these text versions of our Forms, Classlibs, and Reports (see the updated SCCText app here: http://vfpx.codeplex.com/wikipage?title=Alternate%20SCCText). However, using this file is still a tedious way to get your SCC files generated if you try to do it by hand. Sure, the FoxPro IDE can hook into this app if you set it all up and are working on one of the source control systems that VFP was natively designed to work with. But VFP is getting kind of old, and there are many options that exist today the VFP simply cannot work with out of the box.

I recently wanted to use the Mercurial source control repository to manage the development of my GoFish 4 Code Search project. I set up a free project hosting account on BitBucket.org and installed the Tortiose Hg software on my Windows machine, and then I was able to commit code changes to this magic repo in the sky and share it with the whole world.

Sadly, VFP does not have support for this newer Distributed Version Control System, so I can’t “hook up” FoxPro to use SCCText and then “check in” my code in the VFP way.

VFP Version Control with Mercurial

Rick Borup presented a session at SWFox 2011 on using Mercurial version control with FoxPro source code. You can get a free PDF copy of the whitepaper here:

http://www.ita-software.com/papers/Borup_Mercurial_Published.pdf

The CreateSCCText Class

To automate creation of the SCC files, I have created a custom class with a method that recursively calls SCCText for each file in a VFP Project. It’s a snap to use this simple class in a PRG and run it each time right before you commit  changes up to your repo. You can also create a ProjectHook class and include a call this class in the AfterBuild(). It will then automatically create updated SCC files every time you build your VFP project.

It’s DateTime aware for each file, so it will only re-generate the SCC files if the date of the VFP source file is newer than the existing SCC file. This way, when you post your commits, you’re only pushing up SCC files that have changed since the last push. There is also support for skipping over certain files that you may not want to process with SCCText.

I owe a lot of credit to Paul for getting me started on that SCCTextGeneration stuff.  He gave me some helpful code in a UT message when I asked a question about running a process on every file in a Project.  He basically gave me the code to do it in his reply (see message# 1507894).  I just bundled it all up in a class/module and made some noise about it.

You can get the source code for this simple class here: http://codepaste.net/9yy1gm

Other sources for getting and using SccTextX

*UPDATE*  Here’s newer way that I’ve begun to automate the generation of text files from the FoxPro binaries – *before each commit*, I run this code below which calls a Thor Procedure to generate the text files from the pass project (I wrote this Thor Proc and passed it on to Jim and he included it in Thor.)  You can get Thor Tool Manager for FoxPro from the VFPx site. It adds lots of great developer tools to the Visual FoxPro IDE.

Basically, you pass in your project path, and it generates the text files by calling a slightly modified-for-Thor verison of SccTextX that we’ve included with Thor.

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: