Category Archives: Foxpro

How Thor checks and distributes new versions of tools in FoxPro

In this post I will explain how Thor checks for new version and distributes tools from VFPx community like GoFish, FoxCharts, FoxyPreviewer, etc.  I was involved with Jim Nelson at a pretty low level when all this distribute/update goodness for FoxPro via Thor was first being developed. I have emails dated October 2011 where we were working on this, so 6 years ago as of this post in October 2017.

First, look in the Thor Updates folder of your Thor installation. On my machine the Path is:


In this folder, you will find an updater prg for each tool that is available from Thor. In this case, for the FoxyPreviewer app:

Now, open that file and have a look… In this file, you will see it contains all the info that the Thor update engine uses to check for updates and download a tool.

In this case, the current version that Thor publishes ver ‘v2.99z30’ and it pulls the zip file from this website, which is owned by Rick Schummer, and Jim Nelson (along with a few others I think) have FTP access to this server to post the latest ZIP file.

ZIP location:

So, to get a tool updated, Jim has to do 2 things:

  1. Distribute an updated updater prg which will be pulled down when the user from Thor Check For Update. So, he sends out an updated Thor_Update_<<ToolName>>.prg with the new . VersionNumber (or the updater pfg may use a .VersionFileURL property which points to a file on the server which has the new version number) , and a .SourceFileUrl property which has the URL location of a zip file on the server which all the app file in it. Users will see all available updates for any of the Thor distributed apps in the CFU grid.

  2. He, or the tool author, must also post the referenced ZIP file to the server (usually an ftp server at a web hosting account) at the URL path referenced in the updater prg.

With these two things in place, lots a black magic happens (or, white magic, since it is Jim, and he is a good fella by most accounts), and users will see that a new update is available, and if Jim has been living right, it will download and unzip to the users local Tools or Components path in the Thor folder.

Here is the code in thor_Update_FoxyPreviewer.prg

Message Queue solution for Visual FoxPro applications

Download from git repo here:

Job Queues, Message Queues, Message Broker, Asynchronous Processing…  There are many names for this very helpful architecture where you take a process that holds up a user’s workstation for several seconds, or even minutes, and move the work to another machine (i.e. server or other workstation) to be processed offline, “in the background”, aka “asynchronously”,  either immediately or at some later time.

Using some helpful classes from the West Wind Web Connection framework (also available in the West Wind Client Tools package) we can implement a robust Message Queue solution in Visual FoxPro.  All it takes is two simple steps:

Step 1 – Submit a “Message”:  Create and submit a simple Message record to the QueueMessageItems database table which has the name of the Process or Action that you want to execute, along with any required parameters, values, settings, user selections, other other criteria required to complete the task.  Boom… in a blink the local user workflow is finished and they think your system is the fastest thing in the world, because now their computer is free in a few milliseconds and they can resume other tasks.

Step 2 – Process the “Message”: Down the hall, you are running a Message Queue Processor on a server or other workstation that can access the database, network drives, printers, internet, make API calls, etc needed to complete the task.  Once the Message (i.e. task) is picked up by the Processor it is marked as Started, and when all the processing is finished the record is marked as Complete. Along the way you can send other other messages, emails, SMS text messages, reject messages, etc.

Message Queue Monitor – UI Form

A simple UI form allows you to observer all the Message processing as it happens.


Other great benefits of this pattern and architecture:

  • You wind up with a complete log of who submitted what, and when, how long it took, and if there were any errors processing the various messages.
  • You can direct certain types of Message to different “Queues” so that you can halt processing of certain Queues if you wanted to.
  • You can re-process any requests that failed, in case there were errors other reasons that the task could not be completed at that time.
  • You can launch multiple instance of the Queue Processor to handle Messages in one or more Queues if you have heavy workload or wanted to focus horsepower on a certain Message type.

“Multi-threaded” processing

Another thing this allows is that on the “server” (i.e. whatever machine is running the Message Processor app) , you can actually launch MULTIPLE instances of the Message Processor, and that lets it run essentially achieve the performance of a multi-threaded app because you are processing several Messages simultaneously.  FoxPro’s single-threaded architecture can be circumvented with this approach. No need to wait for sequential processing of each Message.  When running on Sql Server, it calls a Stored Proc on GetNextMessage() and it also flags the record as in-process so that other running instances will not pick up the Message.

Example uses

  • Generating and printing reports
  • Sending emails to clients or customers
  • Batch processing that run long queries, Insert, or Update statements
  • Calling external APIs that may have slow response times, or be totally offline that the time the task is initiated.

Specific case

I recently used Message Queue to solve this nagging problem… When printing a particular report from a form in our FoxPro app, the form (and user) is held up for about 3-4 seconds while the report renders and spools. That doesn’t sound like much, but I *hate* waiting that amount of time every time we print a new Shop Order to sent out to production. It happens dozens of times per day for several users.

So… Using the West Wind Message Queue, it now submits a Print Request Message to the Message Queue, which takes about 30-50 milliseconds, and the user form is never held up at all waiting for the report to print.  The Queue Message Manager (which is a VFP app running on the server), picks up the Message and prints the report.

Conveniently, it prints to the default printer defined on the server, which is the main printer central to all users, which is the same one that is the default printer on everyone’s desktop.  If you needed to send the report to a specific printer, you’d just have to add that printer name using loAsync.SetProperty(), then do Set Printer in the Queue Manager code to control where the report comes out.

You can do it too

Consider this asynchronous architecture if you any such hold-up, or long-running-processes that your users wastefully wait for each day on their job.


You can read Rick Strahl’s extensive whitepaper on his wwAsync class. (Note: the whitepaper is kind of old, and the focus there is on how his Web Connection framework uses the wwAsync class to handle back end processing in web apps, but using this on a LAN or desktop/Client Applicaiton works exactly the same way.) Documentation of each method and property can be found here.

.Net Version

There’s also a more robust .Net version of this same framework. It has even more features for managing multiple threads, multiple Queue, and much better live GUI that runs in in a web browser.  It’s an open source project on GitHub :

FoxPro Code samples

Submitting a Message:


Message Processor – handling the Message request


XML data to pass values

The required parameters, values, user choices, etc, are stored on the Message record in an XML field using the SetProperty() method when creating the Message, and can be retrieved using the GetProperty() method when processing a record.

XML example of data stored on a Queue Message:


Here’s what the message look like in the QueueMessageItems table:


Message item data structure

Here is the data structure of the fields used on the QueueMessageItems table. Some of the fields are managed by the Message Manager class, several are available for your use in constructing and processing the message.


FoxPro NewObject() – Fast here, slow there…

The problem (initially posted to Universal Thread 2016-06-28:

I have a VFP9 app that runs against Sql Server. When I run the forms inside the FoxPro IDE, running against the production Sql Server database located on a central server down the hall (i.e. NOT on my local developer machine), all the forms load up and run very quickly.

However, once compiled into an exe and running from the same developer machine, the forms take about *FIVE* times as long to load up. This is very consistent across all forms. The difference is 1.5 seconds load time in the IDE versus 7 seconds load time when running from an EXE.

Is there a particular reason that forms would run more quickly inside the FoxPro IDE than when compiled into an EXE?

The solution

Some background: A basic form in Visual FoxPro 9 my app will create between 30-40 Business Objects when it loads up (yes, those really cool kind of Sql Server Business Objects based on of the West Wind wwBusiness framework). In our system, like most others, an Order has a Customer, and Contact, and ShipToAddress, and vast collection of child items (i.e. cursors), such as LineItems, LaborRecords, MaterialRecords, ShippingTickets, Invoices, etc. So you can see it’s a very robust business/entity model and *every one* of those items I listed has its own formal Business Object to load the respective data and do various pieces of work on the data.

Each business object is a separate PRG: Job.prg, Customer.prg, Contact.prg, JobLineItems.prg, JobShippingTickets.prg, etc… You get the picture. In all, I have about 40-50 of these Businesss Objects, each in a separate prg file).

Each UI form uses a loader function to instantiate each needed Business Object and all other related Business Objects. The loader functions make a simple call like:

Well, guess what I learned…. If you call NewObject() in this manner from within the FoxPro IDE, it runs in about .03 seconds. That’s plenty fast enough for me and my users, but my users don’t run the app from my IDE. They use a compiled EXE app running and in that case, the same NewObject() call takes .21 seconds! Please note that is *7* times longer for each call! Now remember that my forms will typically call this function about 30-40 times, so the results is that the forms will load with startup time of around 1 second in the VFP IDE, but it takes 7-8 seconds when running from an EXE. Are you kidding me? What is going on? (BTW – I discovered this using the Coverage Profiler and a good bit of snooping around in the log results.)

So, the offense that I independently discovered here is that NewObject() is really slow when running inside of an EXE, but very fast when running in the IDE. Can’t explain that, but it’s true.

The remedy was to get away from NewObject() (in by BO factory) and use CreateObject() instead, which also requires the prg(s) to be loaded into memory by way of SET PROCEDURE. So, instead of making 50 Set Procedure calls, I wrote a build task which merges all the separate prgs into a single prg and I added that to the project as an included file, then I added a Set Procedure command for this file in the app bootup sequence.

I then changed my BO loader function to use CreateObject() instead of NewObject():

And, boom, I now get lightening fast creation of each BO even when running in the compiled EXE, and the form now loads in 1 second or so. Users = Happy.

Now, apparently I am not the only one who has ever discovered this oddity before (maybe you already knew it yourself as well), but as I was honing in on what I though the issue was, and what I thought the remedy would require, I happened to do a little Googling and found a 10-year blog post by some dude named Rick Strahl who had himself dealt with this issue before, and confirmed the same exact results and remedy that I landed on. Here is his post: You can also see more discussion on this topic at

Wow! This was a fun day. I love killing these little pests.

Update… Sys(2450,1)

User Walter Meester posted a reply on UT asking if I had tried using Sys(2450,1) which is a flag which “Specifies how an application searches for data and resources such as functions, procedures, executable files, and so on.” (From the VFP Help.)

So, I went back to the NewObject() way, and added the SYS(2450,1) suggested, and did careful, repetitive testing.

Result: Using Sys(2450,1) along with NewObject() does help a little bit when running inside an exe, *BUT*, it is still slower than using SET PROCEDURE along with CreateObject().

There are very distinctive and noticeable speed differences:

  • 1st Place: SET PROCEDURE + CreateObject() = 1.4 seconds
  • 2nd Place: Sys(2450,1) + NewObject() = 5 Seconds
  • 3rd Place: NewObject() alone (leaving Sys(2450) at the default value of 0): 7.2 seconds

I hope this information helps your app performance in some way.

Here are the results I found from the Coverage Profiler for 1st Place and 3rd Place above. (I did not go back and run 2nd Place through the coverage proviler, but you can perceive where it would fall based on the time results listed above.)


Task Pane slow to load in Visual FoxPro

Have you ever noticed that the Task Pane in Visual FoxPro can be very slow when accessing the Community tab?  Well, I found the reason for this, and it’s easy to fix.

The issue has to  do with the deprecation of web site, which causes the Task Pane to load slowly. This can be fixed by deleting some rows of PaneContent.dbf:

I discovered this cause and the solution tucked away on a recent post by Olaf Doschke on Link here:

Quick Peek at Visual Studio LightSwitch

I’ve been curious about Visual Studio LightSwitch for a while. It’s a rapid application development tool from Microsoft which lets you quickly develop HTML/Javascript CRUD apps and small business apps for web browsers and mobile devices (I think it can do desktop apps too, but it uses Silverlight to do it, and I’m only interested in web apps these days.)  LightSwitch is installed out-of the box in Visual Studio 2013 Professional and the new (free) Visual Studio Community 2013 edition.

Note: This is not a deep-dive into LightSwitch. It’s just a quick 5 minute review of what I accomplished in less than 30 minutes piddling around with this thing one evening to get a peek at what it’s like. Before I got started, I had watched this nice video on YouTube and it really helped me jump right in:

I recall hearing at one point, when LightSwitch first came out, that some people proposed it as an alternative to Visual FoxPro, or at least a path forward for FoxPro devs who had never built web apps before or did not want to take the full plunge into the .Net world.  So, I’m curious if any of my FoxPro peeps have taken up with this? If so, let’s hear from you.

Here we go… Basically, I found it dirt simple to get up and running. I just created a new LighSwitch prject in Visual Studio and pointed it to a database in Sql Server Express running on my local developer machine (I already had Sql Server Express installed for other .Net work). Next I picked which tables I wanted to work with in the app. You then add views for any given table, selecting which fields to show.  The initial page layouts are auto-generated for the selected fields, and you’ll quickly have a live list view and edit page running in your browser.

I’ve built real web apps in Ruby on Rails and Asp.Net MVC with Entity Framework, and I’ll tell you hands down from real experience that getting a simple CRUD page alive in LightSwitch is much  easier than in either of these other two platforms. Now, I’m betting there are some real limitations that come with using a simple application framework like LightSwitch. So, I don’t dare suggest that an app built in LightSwicth can compete with all the features needed to build a complex business app. You’ll have to learn more about that for yourself. However, there are lots of examples and forums where you can learn how to include advanced UI or backend code when needed.

Here’s a simple edit page. Just make a change and click the little Save icon in the upper right corner of the screen:


To create or edit the views, you use a treeview designer-like UI in Visual Studio to create rows, columns, groups, fields, as well as a command bar for action buttons and other UI controls. It adds default label captions above each field, but you can override those as well as field widths and other styling options in the Properties window (see blow).


Here is a view of the simple Property Editor showing the various properties you can tweak for each control on the page layout.



Ok, it’s all up to you from here. Watch the video linked above, and try it out for yourself.

Next Step

The next three things I plan to explore:

  1. How it handles lookups, like when you need a dropdown list to choose a value from a lookup table and store the ID in a local field.
  2. Client side, or backend validation.
  3. Showing related child records in a grid on the same page as the parent detail fields.

If my interest is there, and my time allows, I’ll update this page if I accomplish anything with these items above.


LightSwitch on MSDN: (lots of how-to-get-started content.)

MSDN Forum for LightSwitch:

PluralSight courses on LightSwitch:

Free video:

LightSwitch articles on CODE Magazine website:

Does Microsoft Visual FoxPro 9 run on Windows 10?

I’m sure many die-hard FoxPro developers are curious if Visual FoxPro 9.0 SP 2 will install and run on Windows 10. Well, I wanted to be one of the first to find out, just like I did back when Windows 8 was first released in its early preview.

So, let’s find out…

First, I installed Windows 10 Preview (64 bit) in a BootCamp partition on my 15” MacBook Pro. (Don’t worry about this Mac stuff, it’s still just Windows running on live hardware, just like if it were a Dell or HP computer).  That went very smoothly, and I did a full install, blowing away the Windows 8 playground I had been using  that partition, instead of updating it from Windows 8 to Windows 10.

Next, I gently inserted the Visual FoxPro 9 CD that I still have from circa 2004. First, it prompted me to install some “Prerequisites”, which it did with no problems. Next I moved on to the main VFP install, and I took all the defaults, then the CD spun around for a bit, and finally, it gave me a nice message screen stating “Setup is complete” and “There were no errors during setup.”  Looking good so far!!


Next, I downloaded and installed Service Pack 2 for VFP 9, and once again, got this nice little affirming message box:


Finally, I “installed” the VFP 9 Hotfix 3 for SP2 (i.e. copied the replacement files to the correct places per the instructions in the readme file in the zip download).

We now have a promising Microsoft Visual FoxPro 9.0 entry in the fancy new Windows 10 Start menu:


Yes, but does it actually run??

Now, I finally get to find out if we can run the fully patched Microsoft Visual FoxPro 9.0 SP2 Version 09.00.0000.7423 on Windows 10. So, I launch it from the Start menu, and quickly go the Help –> About screen:


One small issue with Task Pane…

If you launch VFP 9 it will initially show the the Task Pane, but you will get a small error in the view area of the Task Pane window. (Don’t worry, I’ll show you how to fix this below.)

Class definition MSXML2.DOMDOCUMENT.4.0 is not found.


The issue is that Task Pane requires MSXML 4.0 Core Services. If it’s not already installed on your Windows 10 machine, you will get this error reported in the Task Pane app from the VFP IDE.

However, this problem is easily fixed… You need to download the MSXML 4.0 Core package from:

Once, installed, now Task Pane will work properly:


Now, let’s run some code…

Okay, it says the right version number all, but we need  run some FoxPro code to make sure this thing actually works…  So, I just downloaded the Thor Tool Manager for FoxPro from, and ran to put VFP 9 on Windows 10 to its first test. Thor uses tons of well-architected FoxPro code to do it’s magic, along with some UI forms, and it makes use of our beloved FoxPro cursors, so I figured this would be a good test.  I selected about 10 of my favorite VFPx tools from the Check For Updates form in Thor, and it nicely proceeded to download and install all the tools, and gave this confirming output for each one on the VFP desktop as it did its work:


I think we’re good folks!

Next, I ran a few of these tools, just to make sure they’d fire off, and they did. I’m pretty certain at this point, that my business apps would work just fine here, if I took the time to finish out this developer setup.

So, I haven’t done any real coding work in the IDE, and I probably won’t any time soon, but from my basic tests in this experiment, it sure appears to me that our old friend Visual FoxPro is ready to continue its legacy of being an awesome development tool, even on Windows 10, and hopefully on Windows 20 and Windows 30 as well.

Finally, here’s a  peak at the whole IDE running in Windows 10. You can see I docked some windows, and you can see the shading effect that Windows 10 adds around the individual windows.


Introducing xBase++ 3.0 aka “Polar Fox“

When I was at SWFox 2013 (as a FoxPro developer) I was curious enough about this Xbase++ thing to attended one of their xBase++ sessions. If you didn’t know, the Xbase++ and SWFox conference merged in 2010.  Conference attendance of the combined groups was about 145 for the 2013 conference.  Overall the xBase++ platform and community seems like a very interesting and thriving one to me. The folks I talked to were just as passionate about their platform as us FoxPro folks are.  It sure looks promising for them to continue on for many more years.

Way back in 2010, Alaska Software announced their next version,  Xbase++ 3.0, code-named “PolarFox”, is coming out in a year or so.  “Polar” coming from the company name, Alaska Software, and “Fox” from the targeted audience for 3.0 as FoxPro developers. Yes, that’s a long time down the road, but in my opinion, they are definitely capable to pull this off. I guess they are not in a big hurry, as I suspect they know they have one chance to get this right in order to draw in some FoxPro people.  The lead developer and a partner of Alaska Software, Steffen F. Pirsig, did one of the sessions. I can tell you that he is one *very* smart, low-level knowledge guy. He knows what he is doing developing languages/platforms from what I can tell.

So, what is PolarFox?

According to their PDF, it’s the “next generation Visual FoxPro development platform.”  Xbase++ has a modern IDE, it’s a compiled platform, and the files are all ASCII, so no more FoxPro binary files like SCX/VCX/FRX, which means it will work better with version control platforms like Git and Mercurial. They are claiming that PolarFox will have many FoxPro features and a high degree of compatibility with Visual FoxPro 9. They are hoping it will be an attractive platform for FoxPro developers to consider.

Here is the description of his Introducing Xbase++ 3.0 session from the 2013 SWFox.Net web site:

PolarFox is the codename of a project at Alaska Software that is not just the next-generation Visual FoxPro. In fact, PolarFox is Xbase++ 3.0 with a clear focus on user interface and visual design capabilities coupled with features such as int64, decimals and Unicode-support. Also covered is the ability of Polarfox to migrate and extend existing Visual FoxPro 9 applications while still being 100% compatible to any existing Xbase++ 1.x/2.x based application.

They have a PDF that explains a lot more about what a FoxPro-to-PolarFox conversion looks like:

From the PDF link above, you will see that they listed the Pros and Cons of shooting for 100% compatibility with FoxPro, noting that in doing so “The Xbase++ language (would) become ambiguous and more complex than required”.  So they are NOT shooting for 100% compatibility, rather,  they claim that “(some) VFP specific commands are added to the Xbase++ language” and that “Proprietary VFP functions conflicting with existing Xbase++ runtime functions are isolated in a VFP namespace”. So, even though there is a very high degree of compatibility between Xbase++ 3.0 and Visual FoxPro 9, you cannot just run your VFP code directly in PolarFox. Rather, they will be providing a migration tool to import your VFP project into the PolarFox world which will automatically handle any syntax changes required for the Xbase++ 3.0/PolarFox world. 

I don’t know exactly what that experience is going to be like, but I will likely give it a test run if they make a trial version available when it’s released.

I was curious enough after the first session to attend *two* more Xbase++ sessions.  In the end, I see their 16-year corporate history and existing community as two real pluses compared to *any* of the other Fox replacements that I have casually studied so far. And the IDE has many of the newer features that are present in modern IDEs that we do not have in VisualFoxPro.

Honestly, I doubt I will ever work in Xbase++ 3.0, but I would say it looks like a very interesting and promising platform to me.

There is not much news on their website about PolarFox yet, but here is their web site: in case you want to keep your eyes on them, or even reach out to them to express interest in PolarFox.

SWFox 2012 was a blast

Hi folks – I am just back at work from my 4-day trip to Arizona for the Southwest Fox 2012 conference, Oct 18-21, 2012 .  All I can saw is WOW!!!  Ok, I can say a few more things that just that…

I had an absolute blast at the conference, saw many great sessions (as in *every one of them*), and, most of all, I spent as much time as I could engaging anyone and everyone who was walking around with a SWFox name tag hanging around their neck. Heck, I even cornered a few of the hotel staff members in the hallway and asked them if *they* wanted to know anything about FoxPro. (No takers, but I did get a visit from hotel security later in the day.)

This was my third time to attended the conference. If God still has me breathing air this time next year, I will be back for number 4.

I know there are some circumstances which absolutely prevent some of you from attending developer conferences, but, I strongly encourage you if there is any way possible that you can be at SWFox 2013, PLEASE, PLEASE, work hard during this next year to allow yourself to be there. You will not regret it!! 

If I could send off my employees to a conference and they come back this excited about doing their job, I’d do it. So, show this message to your boss so he or she will see how excited *you* will be after attending attending SWFox 2013.

The 2013 conference dates are:  Oct 17-20, 2013.


Did I meet Jun Tangunan, the 2012 Ceil Silverman Ambassador?

  • Yes I did. I had several opportunities to chat with him, and he is a very interesting and enthusiastic developer. We’ve already swapped a few emails, and I hope to explore his VFP tools a lot more in the coming months. Read more about him here:

How many people attended the ‘Show Us Your’ App session?

  • I did a quick table and body count… There were at least 60 people present, and 7 presenters (myself included) who did 10-minute presentations.

What did I do for dinner on Saturday night?

  • Walked 1.7 miles (each way) to a cool burger joint named Joe’s Farm Grill with about 12 other FoxPro devs… Bill, Bill’s (wife)?, Joel, Barbara, Eric, Todd, Randy, Michael, Phil, Stein, Art,  and maybe a few others I can’t recall right now. (If you were there, or can add to this list, please let me know so I can add everyone’s name.)

Did I wear a custom-printed GoFish T-shirt one day?

  • Yes. (Photo coming soon.)

Did I fart around on my laptop during any of the sessions?

  • Nope! I purposely left my laptop in the hotel room, so as not to be distracted.

How many session did I attend? 

  • I attended 16 total sessions, 23 total hours.

What were my favorite sessions (in no particular order)?

  • Sql Server 2012
  • Sql Server Mgmt Studio Tips and Tricks
  • Amazon EC2
  • OutFoxThe Fox Report writer
  • .Net COM Interop with VFP
  • Calling .Net Components from VFP

Lifetime Achievement Awards

Congratulations to Cathy Knight and Craig Boyd for receiving FoxPro Lifetime Achievement awards. Thanks to both of for your many years of invaluable contributions to the FoxPro community.

VFPx Administrators Awards

Jim Nelson and I received a VFPx Administrators Award. It’s nice to be recognized for the work, but the people who use it and communicate with me about it are where the real joy comes from. Congratulations Jim!

Sessions I attended

In most sessions I sat on the front row, as I prefer to do any time I am watching anyone present material of any sort. It helps me focus, and not be distracted by others. (Okay, I did send a few FoxPro related tweets from my iPhone.)


  • Intro to C# – Doug Hennig


  • jQuery 101 – Rod Paddock
  • Amazon Elastic Cloud computing (Host a Windows Server in the cloud)
  • ASP.Net COM Interop with VFP – Rick Strahl
  • Chit-chatted  with Andrew MacNeill and FoxFire Reports
  • Unit Testing with FoxMock – Cristof
  • Calling .Net Components from VFP – Rick Strahl
  • Show Us Your App (I presented my Dynamic Forms class)


  • Office Automation without Office (via Google Docs) – Cristof
  • Advanced Topics in Mercurial – Rick Borup
  • More Fox on the Run – Eric Selje
  • HTML5 – Steve Bodnar
  • Sql Server Mgmt Studio – Eric Selje
  • The Dangers of Accessing Sql Data – Kevin Cully


  • Give Me Some Skin – Tuvia Vinitsky
  • SQL Server 2012 – Manachem Bazin
  • OutFox the VFP Report Writer – Cathy Knight


I hope to see a lot of new faces there next year!

Zooming the font size in FoxPro IDE code windows

In this post, I’ll show you how to use the AutoHotKey system utility to make a simple script file to quickly automate zooming the font size up and down in the FoxPro IDE using keyboard shortcuts or the mouse wheel.  This is a common feature in most modern code editors, but it is not a native feature of our much older FoxPro IDE.  (Jim Nelson gave me this idea when he explained you can Enlarge and Reduce the code window font size through the Format menu when you are working in a code window). So, I used AutoHotKey, which is a tool that can be used to create macros and scripts keyboard shortcuts and mouse gesture for any app running on your Windows machine. It allows for very complex hotkey and mouse combinations that FoxPro macros do not support. This quick-zoom feature is something that most modern IDE’s have and I’ve badly wanted this feature in FoxPro for a long time.

Video demo:

FoxPro IDE does font-zooming :

With these hotkeys (Ctrl+NumPadPlus , Ctrl+NumPadMinus)  or mouse (Ctrl+MouseWheelUp, Crtl+MouseWheelDown) you can quickly increase or decrease the font size in the code window, multiple times, if desired, to create a zoom-in or zoom-out effect.


  • ControlKey + the [PLUS] key on the number pad of your keyboard to zoom the font larger.
  • ControlKey + the [MINUS] key on the number pad of your keyboard to zoom the font smaller.


  • ControlKey + [Mouse Wheel] to zoom the font larger or smaller.  Try it in both directions to see which way it goes. If you want to reverse the direction of wheel behavior,  just edit the script to reverse the  WheelUp/WheelDown assignments, or use the X-Mouse Button Control utility to reverse the mouse wheel direction for your whole system.

Here are the scripts:

(Save to your .ahk file, then double-click the file in Windows File Explorer to activate the macros.)

Note that AutoKey allows you to restrict these assignments based on the Window handle, so they will only affect the FoxPro App, as these macros would likely not work in the menu system of any other app.

Go from this:


To this:



by pressing the hotkeys or Ctrl+MouseWheel to zoom in or out as much as you want.

Sublime Text 2 syntax coloring for FoxPro code

I’m constantly reviewing text editors for coding in various programming languages and environments. Recently, Sublime Text 2 has gotten a lot of buzz, so I decided to give it a try, and I eventually wound up testing it on FoxPro code.

It’s got a nice Folder View panel on the side, tabbed edit windows, and tons of cool keyboard shortcuts for doing fancy editor tricks, but the first thing I missed was seeing the beautiful FoxPro language in colorized syntax. So, I dug in to learn how to write a syntax file and added all the keywords that are used in the semi-popular NotePad++ syntax file…

You can download the latest version and read instructions from my GitHub repo:


Here’s what it looks like so far:


To be fair, the same thing is possible in NotePad++, it just doesn’t look as cool: