All posts by admin

To Blog or to Forum Post, that’s the question…

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, oh, and sometimes use my 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.

Crash Course to Web Development for FoxPro and Web Connection Developers

I just received an e-mail announcement for what looks like an awesome jump start class for Visual FoxPro developers to get their feet wet in the .Net Web development arena. Super-smart web maven Rick Strahl plans to give you 3 days of quick start how-to teaching on the .Net / Web development train.

You can attend live or watch on GoToMeeting. It’s a 3-day class, November 5, 2009 through November 7, 2009.

Here is a link with all the details:

(P.S. – Does anyone want to sponsor me?)

The color of your comments

Recently I had a thought that the comments in my code may be getting in the way of me actually seeing the code itself while I’m coding. There seems to be two camps in the code commenting world: (1) Write good code and you should not need comments and (2) Write comments or else you are being lazy and no one will ever be able to work with your code. Well, I’m not here to settle that debate (I fall somewhere in the middle).

So, I had this idea of changing the COLOR of my comments from GREEN to GREY, so that I could still see them, but they would kind of fade away into the background, but would still be there if I took a harder look. I suppose the default VFP comment color must be that classic green color that I’ve been looking at for years, so I’ve changed mine to grey to help me focus better on my code, and not the comments.

Who knows, maybe one day I’ll be a real programmer and won’t even need to write comments at all.

Also, the smart one, Bo Durban, posted this hint on UT (in response to this blog post) about how you are not limited to the base 16 colors:

Did you know…If you set it programmatically, you are not limited to the base 16 colors?:

oReg = NEWOBJECT("FoxReg",HOME(2)+"classes\registry.prg")

So, here are a few screenshots to compare… Give it a try and see what you think.

Grey Comments: Green Comments:

Ruby on Birmingham

In case you’re interested, here is a link to the RubyHam users group in Birmingham, Alabama. They have monthly meetings, usually meeting on the first non-holiday Monday of the month. The meetings are around lunch time, rather than at night. I’ve never been to one the meetings, and I’ve never used Ruby, but I did see a presentation about it once and it seemed cool enough to make me want to learn more about it. I plan to go to the next meeting on September 14, 2009 just to see what it’s all about. Will I see you there?

Ruby is a (non-Microsoft) language that seems to have reasonable popularity among the kids. Microsoft is working on a version for .NET called IronRuby: Since I am indeed a Microsoft fanboy, that will probably win my first dance.

Get involved. Enjoy. The choices are endless.

West Wind Client Tools for VFP

Note: This post if part of a complete series on the West Wind wwBusiness library.

Introducing wwBusiness

An object oriented data access library for Visual FoxPro

I recently got interested in converting my company’s main Visual Foxpro CRUD application to a Business Object model, rather than old-school free .dbf tables with a bunch of procedural code stuck in all the button clicks and textbox valid() events. I’m sure none of you have ever done such hack-work, but back in the beginning (I started with FPD in 1992, then FPW, then VFP as each was released) that’s how I started. I was a solo developer and had no formal training or access to mentors. It took me a long time to get the vision of how real programming should be done, but I finally learned some of these core fundamentals a few years back, and I’m really enjoying the process of refactoring my app into this BO pattern. I began by reading about the topic in all the usual places, and posted a few questions here and there on several VFP sites (like and, then I finally hacked out my own basic BO class, after I learned about the SCATTER approach that is widely used to capture data from a table row into an object.

Then, at a pair programming session with a Foxpro developer friend of mine, he showed me Rick Strahl’s West Wind Web Connection for VFP that he’s used for years. Turns out that package has a nice BO class library, called wwBusiness, which is also available as part of a client app tool set from West Wind (called the West Wind Client Tools for VFP ). So the Web Connection package and the Client Tools package both have the same wwBusiness BO class library.

Now, the West Wind Client Tools package also has a TON of stuff besides just the BO classes (like SMTP, HTTP, FTP, SQL, XML, JSON, SOAP, blah, blah). You can read all about them at the Client Tools page link I listed above.

One cool thing about the wwBusiness BO class is that it has one single property (nDataMode) to switch between VFP dbf tables and SQL Server, so it’s very helpful if you want to migrate your application’s data to a SQL Server backend and flip the switch once you are ready to move away from dbf tables. And the cool thing is that your app will never know where the data comes from, it just uses the wwBusiness BO to request data, and it comes back as an object that you can work with, then you call the .Save() method on the BO object to write the changes back to the DBF or Sql Server. I tested it, and it actually does work very well.

The wwBusiness.vcx class library has two class types:

  • wwBusiness – a single BO class (for fetching a parent record or a single line item)
  • wwItemList – a class which will fetch and hold a set of records (like line items on a Sales Order)

Together, these classes can model just about any Parent-Child data set you might have in your app.

Introducing wwBusinessPro

I found the two base classes in wwBusiness be good starting points for basic Object Oriented data access, but I have written my own wrappers around them and extended their functionality greatly, and I’ve named my enhanced library “wwBusinessPro”.


You can download wwBusinessPro from the project hosted on


The wwBusinessPro library extends the base features of wwBusiness by adding these new features:

Here are the primary two ways I extended the classes:

  1. The wwBusiness (single BO class) expects an integer PK to do lookups and fetches. I indeed have Integer PKs on my tables, but I sometimes also have a unique lookup string for each parent record, and I wanted the option of using that for fetching a Parent record (and related child records too). So, I created a Get() method which will accept either an Integer or a String. It then calls the native wwBusiness.Load(tnPk) for Integer PK lookups or it will call my extension method LoadByRef(tcLookupString) for string based lookups. The wwBusiness class already had cPKfield out of the box, and I added a cLookupField property to handle string-based lookups. I also enhanced the Save() method to apply the Parent Key to all the Child collection records so that the relational structure required for Parent-Child PK/FK would be automatically handled for me.
  2. Out of the box, the wwItemList class requires YOU to write a method to fetch the desired child records into a cursor, then it loads that data from your cursor into an array when you call the wwItemList.LoadFromCursor() method. Well, that array would work fine for procedural processing, but for my application I needed to host the child records in a grid, so I needed to service the child records from that local cursor (rather than working on the array items). I wrapped the wwItemList Save() method to get the local records back into the real table from which they came. For my app design, this cursor-based functionality was the biggest missing part from the basic toolkit. I had to write about 3 or 4 methods to handle this workflow in an abstract way so I could have a generic solution for all my child item collections. The main methods I wrote were LoadLineItems() and a wrapper around SaveToCursor() which was needed to handle records that had been deleted from the local working cursor.

You can see a code sample of working with my extended wwBusiness classes here:
Here is a screenshot of the object model that I created with my extended wwBusiniess and wwItemList to create a Job object with several associated child collections: Line Items, Material Items, and Labor Items that are all from child tables related to the Parent record via PK/FK relationship.


Lastly, note that using a BO tool in general not only brings you data handling in an object-based manner with support for various back end data stores, but that same Business Object now becomes *THE* place to put business logic for each of your business objects. Like adding a method for CloseSalesOrder() or AssignJobPriority() or SetDefaultPropertiesForNewJob(), or PrintShippingTicket() etc. With all this properly in place on your Business Objects, creating a UI form becomes a much simpler task of just calling methods on the Business Object. Using this technique, I was able to reduce the code in my CRUD forms by more than 50%!! And now, I have a bunch of cute BOs I can instantiate in code or even right in the command window to work on them without even having a UI screen. Not only that, the same BO can easily support a web-based UI to your same exact data and business logic. It is truly beautiful!

So, as you can see, I did a lot of work on the West Wind classes to prepare them for my app, but two things: 1. It was VERY fun to work all this out, and 2. It works like a charm, and I now have a completely BO-based CRUD app where all the Business logic is nicely tucked away in the BOs and not in my forms or form controls.

Also, FoxPro veteran Kevin Cully is a long-time West Wind user, and he made a presentation on the wwBusiness classes to the Atlanta FoxPro User Group (AFUG) several years ago and prepared a nice 20-page introductory paper here:

Man, I wish I had this thing 10+ years ago when as I first began the VFP version of my app. Since I didn’t have a clue what I was doing at the time I started, it wound up a little bit messy, until this came along. I began my own BO efforts around May 2009, and the I abandoned my version in favor of wwBusiness around August 2009.

So go check it out for yourself… You can read the help file online and the package is only $199, and has 10% during August 2009, so about $179 gets you on his customer list and into the surf over at West Wind. You can download a working version with the full source code right from the site. The site also has a reasonably active discussion forum, and Rick is generally very responsive himself.

Note: This post if part of a complete series on the West Wind wwBusiness library. Click here to see the full index.