Thoughts on Metro and the Windows Runtime

Like many developers, I spent much of last week and the weekend watching the Microsoft BUILD conference and learning about Windows 8, the new Metro UI, and the Windows Runtime (WinRT).  My first impression of the Metro interface was that it is compelling and I like it.  That has faded a bit as I get into the details of what you can and cannot do with the new architecture.  There is a lot to like about the Metro user and developer experiences, all of which you can learn about at Microsoft and the blogosphere.  As a developer, I’m thinking along the lines of how I can use the new technology while preserving my investment in existing code and skills.  Restrictions built into Metro (by design) have a direct impact on that.  While highlighting all the cool new stuff, Microsoft has glossed over the restrictions a bit, so this post looks at things from that point of view.  First of all, I should say that this is a developer preview, Microsoft is looking for feedback from developers on their design decisions, and some of those decisions may change before release.

The more I learn about Metro/WinRT, the more I realize it is “Windows” in name only.  To start, there are no windows in Metro!  Everything is full screen.  While there are some things shared under the hood (like the Windows Kernel and file system), for the most part, Metro is separate and isolated from the Windows “desktop”.  Metro competes directly with Apple iOS and Google Android in the tablet space, while also being available to PCs. That much is obvious, but being bundled in Windows, you might think you also get access to all the goodness in the Win32 and .NET APIs.  That is not the case.  This really is two operating systems in one box.

So, why not just sell Metro separately as a new OS?  Microsoft already tried that. It’s called Windows Phone 7, and nobody’s buying.  Even Windows Vista had 400 million users, so bundling Metro with Windows ensures there is a viable market for apps.  Besides, we developers would freak out if Microsoft dropped Windows for something entirely new.  Putting Metro in Windows is good all around.

A key point to make is that Metro is client-side technology only.  In spite of support for HTML, these are desktop apps.  The HTML is not served up by a server, but rather is compiled into the Metro app.  Being client-side technology, there are a lot of things Metro doesn’t do.  Microsoft expects your business logic and database access to be done on the server and exposed as a service that Metro apps can consume.  Of course, they would be happy to host this service for you in Azure, but that is not a requirement.

How about the Windows Runtime?  What exactly is it?  It could have just as easily been called the Metro Runtime, because it exists for the sole purpose of servicing Metro apps.  Under the covers, WinRT components are written in native C++ (take that Dev Div!), and interfaces are exposed using COM and metadata.  This does not mean that COM is making a comeback in Metro.  Microsoft has used COM (specifically the IUnknown interface) for years as a means of exposing native interfaces, and they are simply using that rather than reinventing the wheel.  There are no type libraries, rather interfaces are described in a modified version of the .NET metadata format called winmd.

So, if you’re thinking about accessing the WinRT from FoxPro or other environment using COM, you can forget about that.  In fact, this whole notion of automating other applications is absent from Metro.  You cannot directly start another application and communicate with it from Metro.  This applies to both Metro and desktop apps.  You can send info to another Metro app via “contracts”, such as the Share contract in Metro.  But you can only use contracts provided by Microsoft, and these contracts can only be initiated by the user, not in code.  If you do need to communicate with another app, even on the same machine, then you’ll need to use network protocols, such as IP sockets, http, or web services.

With all this hype, what is Metro replacing?  Something has to die, right?  I’m sure each of us will draw our own conclusions on that, but I will say that Microsoft always emphasizes the shiny new thing.  That doesn’t mean existing MS technologies will go away, or that MS will stop investing in those technologies.  At the same time, Microsoft is clearly investing heavily in Metro and will continue to do so, at least until the next shiny new thing comes along.  From a technical point of view, to the extent that you can port your code (based on restrictions) and that you choose to adopt the Metro design, Metro replaces almost everything.  If every desktop app were rewritten in Metro, then it could even replace Windows as a whole.  It’s hard to know what Microsoft’s aspirations are in this regard, but based on the targeted nature of Metro and its capabilities, I don’t see this happening, not for a long, long time, if ever.  From the point of view of each technology…

.NET: I can unequivocally say that the .NET Framework is here to stay.  Since Metro is only client-side technology, you will need something on the server side, and Microsoft will continue to push .NET for that.  When building C#/VB apps, Metro does use the .NET Framework, however it restricts you to a subset of functionality.  For example, you cannot use the System.Data namespace, which means no ADO.NET, which means you can’t access a database directly from Metro.  You’ll need to build the data access into the server side using .NET.  For what it’s worth, I believe Silverlight has the same restriction.  Microsoft seems to be deciding what the .NET restrictions are based in part on what they did in Silverlight (more on that topic at  Lastly, do I even need to mention ASP.NET?  Browser-based web apps aren’t going anywhere.

Silverlight/WPF: As far as being deprecated, I worry about Silverlight the most.  MS will be pushing Metro on the desktop and HTML5 through the browser.  Some will say that WPF is already dead.  On the other hand, PhotoShop was shown at the keynote and given as an example of an app that would NOT be appropriate for Metro, due to its dense UI design with a focus on productivity.  Many line-of-business applications could be described in the same way, so there is still a place for these technologies.  As it stands, there are new versions coming out for both, but beyond the next version, we don’t know.  Now that the XAML group is part of Windows, Metro will no doubt get the lion’s share of the resources, but I hope investment continues on Silverlight and WPF.

Win32/C++:  For the most part, C++ developers will be using WinRT in Metro rather than the Win32 API.  MS does allow access to a subset of Win32 APIs that have functionality not addressed in WinRT (, but at this level, WinRT and Win32 really are separate worlds.  That said, Win32 is the most used API on the planet. Even if MS doesn’t invest another cent into it, it will be here a long time.

Let’s talk about preserving your existing investments.  Microsoft is focused on making sure your existing skills can be used when building Metro apps.  That is, as long as those skills include HTML/JS, C#/VB, or C++.  You might even be able to port existing code into Metro, but it’s not copy and paste, and it has to adhere to the restrictions.  Microsoft demoed porting existing XAML and code from Silverlight and Windows Phone apps that were already written in the MVVM pattern used by Metro.  If you want to move from a Windows Forms UI, I doubt there is much you can keep, and you’ll be rewriting the UI in Metro.  From FoxPro, you don’t get to keep anything, except what you use on the server side.  I’m not a C++ developer, but I imagine porting C++ code would involve replacing Win32 calls with WinRT functionality. I don’t know how feasible that is, so you may be able to bring in code that doesn’t reference Win32 (good luck finding some) and rewrite the rest to use WinRT.

As far as compiled libraries, you can’t just add a reference to a .NET DLL in a Metro app.  You can, however, create a “Portable Library” that can be called from both Metro and standard .NET, as long as the library sticks to the Metro subset of .NET.  I don’t know how this works in C++, but it may be the same story.  MS showed bringing the Boost library into a Metro app, but I don’t know if that was Boost source code or a compiled library.

Moving on to user interface… Microsoft is providing developers with clear design guidelines for Metro apps.  Designers may not like being told how to design their apps, but I don’t think it is a requirement that you follow the Microsoft rules.  Personally, I am glad that Microsoft is providing guidance on Metro design, because we got no such guidance with WPF or Silverlight.  How many times have you seen WPF or Silverlight session where the speaker says “I’m not a designer…”, and then proceeds to show a crappy looking UI that makes you wonder why you would want to use the technology at all? With Metro, I can use the MS templates, follow the guidelines, and end up with an attractive, functional app.  If I want to do something extra special, then I can get a professional designer involved.

What about deployment of Metro apps? You will be able to use “side-loading” to test and debug your apps on a limited number of devices.  Otherwise, you can’t directly install your Metro app on a device.  It must be deployed through the online Windows Store.  Each app you upload will be certified against a series of tests to ensure compatibility and compliance.  So, if you’re thinking about using some tricks to get around the restrictions I’ve already mentioned, that may work on your machine, but the certification tests will fail and you won’t be able to deploy your app.  Microsoft hasn’t released details yet, but most expect they will do the same as the Windows Phone store and take 30% of the price of Metro apps.  You may have heard that the store will be free, but I believe that is only for the listing of Windows desktop (non-Metro) apps, in which case, MS just links to your site, but doesn’t handle deployment.  There will also be an enterprise deployment option for companies that want to deploy apps internally.  Apple charges $299/year so that you can distribute code YOU write to devices YOU purchased.  That’s not a lot of money, but it just rubs me the wrong way, so we’ll see what Microsoft does in this regard.

So, Microsoft has Metro locked down pretty tight.  Metro limits you to a subset of .NET. You can’t automate other applications or reference existing “desktop” DLLs.  MS forces you to deploy through their store and takes 30% off the top.  This is not characteristic of the Microsoft we have worked with all these years, but they are following Apple’s lead.   At the same time, by exerting this level of control, Microsoft can ensure the integrity, stability, and security of the Metro experience.   The restrictions prevent outside code from polluting and compromising the Metro environment.  If that all seems a little too Big Brother to you, you still have the option of creating Windows desktop and HTML applications without the restrictions, both of which can still be touch enabled.

With all of this in mind, should you run out and rewrite all of your applications for Metro?  Every day, I work on a FoxPro line-of-business app with a heavy emphasis on data entry and productivity.  The fact that we’re still using FoxPro should tell you that we don’t jump at every new technology that comes out of Microsoft.  But, even if this were a WPF or Silverlight app, I don’t think it would be a good candidate for the Metro style.  Maybe that’s a lack of imagination on my part, but displaying info one screen at a time or with a bunch of panning or scrolling would cause a large hit to productivity.  Now, are there pieces of our app that I could expose to a wider audience using a simpler interface with touch capabilities?  Yes.  And the developer and user experience in Metro is compelling enough that I might just target it over an HTML interface that works on multiple devices.  I’m looking at Metro as an environment where I can offer new apps and experiences to users when it makes sense, not as a replacement for existing technologies.

ParallelFox and HyperThreading

Years ago, Intel added a HyperThreading feature to their CPUs before dual-core processors were available. More recently, Intel reintroduced the technology into their “Core i” series of processors. What is HyperThreading and how does it affect ParallelFox? Let’s start with the Wikipedia description:

Hyper-threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources. This allows a hyper-threading processor to appear as two “logical” processors to the host operating system, allowing the operating system to schedule two threads or processes simultaneously. When execution resources would not be used by the current task in a processor without hyper-threading, and especially when the processor is stalled, a hyper-threading equipped processor can use those execution resources to execute another scheduled task. (The processor may stall due to a cache miss, branch misprediction, or data dependency.)

What this boils down to is that a single thread/process will not utilize all of the execution “slots” or “units” in a CPU core. This is especially true when the processor is “stalled”, meaning that the processor is waiting on something before it can continue. This may be due to the inherent design of the CPU, or because it is waiting for data to be accessed from main memory. HyperThreading allows a second thread/process to utilize the unused execution slots. Generally, this is a good thing and can provide a 15-30% performance boost to parallel processing.

However, in cases where there is heavy competition among threads for the same execution slots and other resources, HyperThreading can be slower than running a single thread on each core. The examples that ship with ParallelFox exploit this weakness. On a single-core HyperThreading CPU, the “after” examples are actually slower than the “before” examples. Of course, this was not intentional. The reason is that the examples simulate work rather than resemble real-world code. Here is the SimulateWork() function:

Procedure SimulateWork
   Local i
   For i = 1 to 1000000
      * Peg CPU

While this code does a good job of pegging a CPU core at 100%, it also causes the same few instructions to be executed millions of times. With HyperThreading enabled, competition between the two threads for the same CPU resources is extreme. In a real-world scenario, there would likely not be this much competition for resources and HyperThreading would be beneficial.

As with most things, your mileage may vary. If you find that your code runs slower with HyperThreading, you can tell ParallelFox to use only half of the “logical” processors and start only one worker per physical core. Here is example code for that:

* Use only physical cores
If Parallel.DetectHyperThreading()
   Parallel.SetWorkerCount(Parallel.CPUCount / 2)

ParallelFox uses WMI (Windows Management Instrumentation) to detect if HyperThreading is enabled. WMI has shipped with windows since Windows 2000. However, WMI can only detect HyperThreading on Windows XP SP3, Windows Server 2003, and later versions, because that is when Microsoft introduced the required APIs. On previous versions of Windows, Parallel.DetectHyperThreading() will always return .f. even if HyperThreading is enabled.

There are several other features I want to add to ParallelFox, but at this point, I think it is feature complete for version 1.0.  Also, very few issues have been reported from previous versions, so I am moving this release up to release candidate status.

Download ParallelFox at VFPX.


ParallelFox 0.7 Released

I just released ParallelFox 0.7 on VFPX.  This release features… wait for it… documentation!  That was the big piece missing from ParallelFox.  I created ParallelFox.chm with West Wind’s excellent Html Help Builder.  The help file is designed to be used in conjunction with the training videos I made previously. Use the help file as a quick reference or short overview of topics. Watch the training videos for more in-depth discussions, examples, and techniques.

This release also includes improved IntelliSense. ParallelFox takes advantage of Doug Hennig’s Favorites for IntelliSense, which Doug also used in the My project for Sedna. This greatly simplifies the ParallelFox interfaces and provides extra details while you are coding.  See the “installation” topic in the help file for details.

There were a few minor tweaks/improvements made to the source code as well.  If you have any questions or comments, I will be watching the discussion area on VFPX and the VFPX/Sedna category on Universal Thread.


FoxTabs Finally Hits 1.0

Five years in the making (I say that like it’s a good thing), or even longer if you go back to when I first started playing with this concept, FoxTabs has finally reached the coveted “production release” status on VFPX.  Actually, it has been stable for quite some time now, but since FoxTabs works so closely with the internals of VFP, it’s the kind of project you want to let incubate for a while so you can shake out all the bugs.  Causing C5’s in the VFP IDE doesn’t win you any popularity contests!  Many developers have been running it, and the few bug reports I get are pretty obscure, so I feel confident in moving it up to production status.

Download FoxTabs 1.0 now!


Debugging in ParallelFox

ParallelFox 0.6 Beta was released today.  Earlier this week, I posted a couple of new training videos about Worker Events on VFPX.  When I started, I figured the training video would be 30-45 minutes to cover all the features in ParallelFox.  I’m now up to 4 videos clocking in at almost two hours.  Part of that is my slow presentation (sorry for that, I was doing most of it off the cuff), but if you’ve ever put together videos like this, then you know how time consuming they are.  I feel like it was important to actually demonstrate those concepts in action, but for the rest of the topics, that is not a requirement.  It will be quicker for you and me if I present the remaining topics in written form, and this is the first entry in that series.  I will link to all entries from the main ParallelFox page on VFPX.  Occasionally, a video may be called for, in which case I will create a short video and link to it from the associated blog entry.  These entries may someday make their way into a Help file.  Ok, let’s get started with the first topic…

FoxPro does not allow you to debug into COM servers.  To spell that out, suppose you created a COM server in VFP, and then instantiated that object in VFP as well.  The code would look something like this:

Local loMyCOMObject as MyCOMServer.MyObject
loMyCOMObject = CreateObject(“MyCOMServer.MyObject”)

Set Step On


In the code above, Set Step On would open the debugger, but if you tried to step into the DoSomething() method, you would not be able to see the code inside the COM object.  VFP would execute the method then return to the calling program.  Calling Set Step On (or setting a breakpoint) inside the COM object doesn’t work either.  To work around this, you have to instantiate your objects as regular FoxPro objects and fully debug them before building them into a separate COM server.

Aside: Years ago, Robert Green and Calvin Hsia demonstrated debugging FoxPro COM objects from Visual Studio. This was around the time Microsoft introduced .NET, and even though they had already decided there would be no VFP.NET, VFP still needed a good integration “story” if it were to remain part of Visual Studio.  You know the rest of the story.  The Fox was taken “out of the box” before the release of VFP 7.0, so it no longer needed that story, and the feature was dropped.

This limitation could pose some problems for ParallelFox, because code is run in parallel by means of COM servers.  It is not convenient to simply instantiate an object in the main process, and the code you are running in parallel may not be inside a class anyway.  Even if it were convenient, the code would be not be running in parallel, only in the main process, so it’s not exactly an ideal situation.

Fortunately, ParallelFox makes it easy to debug your code by providing a debug mode.  To turn on debug mode, simply pass .T. as the third parameter to the StartWorkers() method:

Local Parallel as Parallel of ParallelFox.vcx
Parallel = NewObject(“Parallel”, “ParallelFox.vcx”)


This tells ParallelFox to start the workers in full instances of VFP, rather than as standard COM objects.  Simply SET STEP ON in your worker code (breakpoints may not transfer to worker instances), and the debugger will open in the worker instance.

To use debug mode, the main process needs to know where ParallelFox.vcx and WorkerMgr.vcx are, so make sure they are in your path.  If you’re going to use the Worker object, the worker processes need to know where ParallelFox.vcx is as well, so make sure your workers can find it before you instantiate the Worker object.

Introducing ParallelFox

ParallelFox is a parallel processing library for Visual FoxPro that I’ve been working on for a little while now. Parallel processing is getting a lot of attention these days and with good reason.  Parallel extensions/libraries are popping up for all languages/platforms, and if VFP were still in development at Microsoft, I’m sure the Fox Team would be hard at work on adding those features for us.  But, that’s no reason for us to do without.  FoxPro developers can benefit from parallel processing just like everyone else, and ParallelFox aims to help us do that.

The first Beta release of ParallelFox is now on VFPX, along with a couple of training videos.  The plan is to provide more videos, but there is a lot to cover and it is slow going.  In the meantime, there should be enough info on VFPX to get you started.  Please download ParallelFox, play with it, and let me know what you think.

FoxTabs 0.9.2 and Multiple Windows Event Bindings

I know… I’ve been seriously neglecting my FoxTabs duties… again.  After a long delay, FoxTabs 0.9.2 has just been released.  There have only been a few issues since the last release over a year ago.  Unless new issues are introduced in this version (very possible), I expect this version will become a release candidate, and then version 1.0.

One of the reasons for the delay was an issue discovered by Greg Green, and I wasn’t sure of the best way to handle it.  Greg has created several replacements for the standard VFP editors and designers.  (If you are interested in Greg’s work, go to the Universal Thread Downloads page and enter GKK in the Search field.)  FoxTabs and Greg’s editors were conflicting with each other.  We were eventually led to this statement in the VFP Help for BindEvent():

When binding to Windows message (Win Msg) events, only one hWnd to Windows message pairing can exist.

Greg and I were trying to bind to the same Windows events, but “there can be only one”, so we were stepping on each other’s bindings.  Greg developed a small framework to work around the limitation, and I made some modifications to that for the latest FoxTabs release.

VFP does support multiple bindings for standard FoxPro events.  The solution we came up with adds an object to a collection for each Windows event and binds to that event, effectively translating the Win Msg to a standard Fox event.  BindEvent() is called again to bind the collection object to the intended event handler/delegate. This design allows as many bindings as you want.  The code includes two functions: BindWinEvent() and UnBindWinEvents().

BindWinEvent() has the same interface as the standard BindEvent() function:

BindWinEvent(hWnd | 0, nMessage, oEventHandler, cDelegate [, nFlags])

UnBindEvents() is similar to the standard UnBindEvents() function, but adds a couple of parameters.  Since multiple bindings are now possible, you have to specify which event handler/delegate you want to unbind:

UnBindWinEvents(hWnd | 0, nMessage | 0, oEventHandler, cDelegate)

You can pass 0 to nMessage if you want to unbind all the messages for a hWnd, such as when a window is closed/destroyed.  The following syntax is also supported if you want to unbind all events from an event handler object:


Clear as mud?  The bottom line is that it is recommended you use these functions instead of the standard VFP functions when binding to Windows events.  If everyone does that, then we won’t step on each others toes.  Unfortunately, that is a requirement.  There is nothing we can do to prevent another program from taking over your events with the standard VFP functions.

The code is included in FoxTabs 0.9.2 and is attached.  If you find any problems, please let me know.

SW Fox 2009 Sunday

Sunday rolled around, and I couldn’t believe it was already the last day of the conference.  Sleep deprivation was starting to set in, and I had more sleep than most.  Still, I wasn’t about to miss any sessions.

VFP and MySQL: Case Study for Remote Data
Rick Schummer

For the purposes of this session, “Remote Data” meant using a database server that resided anywhere, on a local server or out on the internet.  Rick started off with some client/server basics and the various ways you can access remote data from VFP.  It’s common knowledge that SQL Passthrough is the fastest method for accessing remote data, or is it?  Rick showed that in some cases, remote views can actually be faster.  It depends on your scenario, and as VFP has improved, statements about performance that were true in previous versions may no longer be true.  So, you should test performance for yourself, rather than making assumptions based on past results or what you heard from someone else.

Rick then demonstrated connecting to a MySQL server hosted on for his site  Even through a slow connection at the conference, performance was quite good.  An upsizing wizard for MySQL is available called Stru2MySQL_2.

Developing and Extending the Visual FoxPro Grid Object
Jody Meyer

Jody is one of the excellent people I met at Southwest Fox this year.  This was Jody’s first time speaking at a Fox conference, and she did a great job.  Her grid class is awesome, or “full of awesome” because nowadays awesome is apparently measured in quantity (get off my lawn!).  Anyway, it’s good.  Not only does is make building grids a snap at development time, but you can give it to your customers to add/remove columns, sort, filter, export, slice, dice, and do pretty much anything you can do with a grid.  No more waiting for the next release to add a column to the grid.  They can do it right now.  Sweet.

Practical Uses for GDIPlusX
Doug Hennig

Being the last regular session of the conference, I was hoping to see some cool stuff to keep me awake.  Doug did not disappoint.  After a brief introduction to GDIPlusX, Doug demonstrated several practical things you can use it for: scaling/rotating images, properly measuring text width/height, creating images from text and adding effects (shadows, etc.), fully justified text in reports, gradients, lightboxes, screenshots, etc.

Closing Session
Tamar Granor, Doug Hennig, Rick Schummer

The closing session is usually brief at Southwest Fox.  There were some giveaways and Southwest Fox 2010 was announced.  One of the slides was titled “Fun, Fun, Fun”, and Doug said this was the funnest conference ever.  For me, that was definitely true, and others have said the same thing.  That is in no small part because the Feltman’s opened their suite to attendees, so special thanks to Mike and Toni for doing that.

The party was by no means over.  The speaker dinner was at room 709, after which attendees started to cycle in.  Since I didn’t have an early flight, I hung out until about 3:00 AM.  Overall, I had a great time this year.  The Fox community is a tight-knit group, but it seems even tighter after this conference.  I can’t wait until next year!

SW Fox 2009 Saturday

Saturday morning started off with three sessions on architectural/OOP topics, so I was looking forward to it.

Data Driving Applications
Toni M Feltman

Toni is another of my favorite speakers and I love her speaking style. There have been previous sessions about using meta data in frameworks, but this session was more about refactoring legacy code (there’s that subject again) into data. A real-world example she gave was code that ran for specific users. The users were defined by an IF INLIST(“USER1”, “USER2”, etc.) command that was duplicated many times throughout the code. If that sounds ridiculous, perhaps you have seen CASE statements that run custom code for specific clients. The problem is the same: the users/customers are hard-coded into the app. The first thing Toni did was pull the user list into a separate function. This was easy and low risk, and when users changed, they only had to change the list in one place. Later the user list was refactored into a table with the appropriate permissions. Rather than have someone manually add all the users to the table, she did it right in the function and added users automatically with default permissions. The session eventually led to creating memo fields where users could create their own code or expressions without having to touch the main EXE. Another good session.

Getting Your Head Around Business Objects
Tamar E Granor

Business objects are a concept that can be hard to grasp. All too often the technical benefits are highlighted of separating your code into tiers, but what makes it a “business” object? Tamar asserted that the architectural benefit of consolidating your business rules into an appropriate place is more important than the technical benefits. She talked about a fascinating project that used FoxPro to manage network hardware. Since the interface was not tightly bound to data, it forced her to think about how code should be separated into business objects. She then demonstrated the concepts using a Suduko game. There were a lot of objects flying around, but there was a clear separation of concerns and it was interesting to see all the objects interact. Tamar emphasized the idea that business objects are the “engine of your app”.

Advanced Principles of Solid Object Oriented Design
Alan Stevens

This was originally going to be my last session of the conference, but being a “big idea” session, I knew it would be better if I tweaked KOKOPELLI to move it sooner before my brain was completely melted. 🙂 SOLID is an acronym coined by Robert Martin for key OOP design concepts. I won’t go into the details here, but Alan did a good job of driving home the ideas with both metaphors and code.

FoxCharts – Great Looking, Modern Charts in Pure VFP Code
Jim Nelson

All I can say is “Wow!” I had no idea how far along this project had come. Jim demonstrated some impressive charts and functionality, and it is all done in a FoxPro style. FoxCharts is every bit as good as commercial options, if not better.

Christof Wollenhaupt

One of the most popular tools for working with data is Excel, which is ironic considering it is not a database. Nevertheless, our clients demand it and we provide. VFP, of course, has built-in commands that make this a snap, but the result is not exactly presentation quality. COM Automation can be used control the formatting and works pretty well, but it can be very slow. Christof presented another option: XMLSS (XML Spreadsheet), a format introduced in Excel XP (a downloadable plug-in is available for Excel 2000). It allows you control over formatting, but since it is just XML, you get VFP’s text handling speed. There are limitations, but if you can work within them, the result is orders of magnitude faster than automation.

Microsoft Virtual PC for VFP Developers

Doug Hennig

I have heard good things about virtual machines. I’ve never taken the time to try one, so I was ready to see the technology in action. Doug presented Microsoft Virtual PC 2007, which is available for free. As you might guess by the name, it runs an emulated PC inside a window on your desktop. It’s an emulated 32-bit machine with a hard drive, network card, sound card… the basics of what you expect in a typical computer. That being the case, the answer to just about every “How would you do this or that in VPC?” question is “How would you do it on a standard computer?” When you boot up a VM for the first time, you install the OS, service packs, updates, anti-virus software, and any other applications you want.

VM’s are good for testing software, testing installations, and isolating your development environment. Basically, if you don’t want something screwing up your main Windows install, set up a VM and do it there. VPC includes good tools for managing it all. As always, Doug gave an excellent presentation, and now I can really see the value of using virtual machines.

After Hours

Several speakers and attendees went go-cart racing at a local track. I will let the winners gloat over their respective victories. 🙂 Rather than embarrass myself on the track, I headed back to the room to get a little bit of work done and to post on this blog, with the intent of meeting everyone back at Club 709 after the races. By the time 11:00 PM rolled around, I couldn’t keep my eyes open. I wimped out and went to bed, but still a good day.

SW Fox 2009 Friday

In spite of staying up too late, I woke up well before the alarm went off. That’s a common story at the conference as everyone tries to adjust to the time zone difference.

Open Source Tools
Menachem Bazian

I saw Menachem for the first time last year, and based on that, I knew this session would be both entertaining and informative, a good start to the day. I was not disappointed. The intent was to introduce several tools and overall to recognize how much good free and open source stuff is out there, just waiting for you to try it. We looked at Notepad++, MantisBT (bug tracking), VirtualBox, and others. Menachem has an obvious passion for open source, but he hasn’t abandoned VFP and other Microsoft software out of spite. He commonly connects VFP to MySQL databases. He also was very clear that “free” tools still have a cost in terms of time and resources, and it may still make sense to pay for software that meets your needs. It was a balanced discussion and I enjoyed it.

Enhancing the Visual FoxPro IDE with VFPX Tools
Rick Schummer

I knew this would be a good session. Rick’s passion for VFPx is contagious. This session was focused on VFPx tools for the IDE vs. things you would use in an application. He showed ClassBrowserX, PEM Editor, FoxTabs, Tabbing Navigation, Control Renamer, ProjectHookX, and probably a few others I missed. It is just insane how much Jim Nelson has done with the PEM Editor in a short time. Tamar’s Control Renamer does more than the name suggests, going through the source code and changing references to the old name, in effect becoming a refactoring tool. In case your wondering how it felt to see my contribution (FoxTabs) being featured in front of an audience, the answer is PRETTY DAMN GOOD! Get involved. You won’t regret it.

Top 10 (or more) Reasons to Use the VFP Toolbox
Tamar E Granor

I love Tamar’s teaching style. She has a way of making things so clear and easy to understand. I admit I rarely use the toolbox. I’ve been using the form controls toolbar for so long, it’s hard to break the habit. Besides, the toolbox is just a better controls toolbar made to look like the toolbox in Visual Studio, right? Wrong! There are so many cool features that help avoid all those little extra things you have to do and overall make your life easier, and you can use it right now. If you aren’t using the toolbox, take another look.

Simulating Multithreaded Processes in VFP
Steve Ellenoff

We have a project coming up where a dashboard type interface needs to update itself automatically in the background every few minutes without tying up the rest of the app, so this topic is definitely relevant. Steve showed a couple of different techniques for simulating multi-threaded behavior. The first involves using functionality already built into VFP: AutoYield, DoEvents, Sleep WinAPI, and Timers. These are all things I have used before, but looking at them from a multi-threaded point of view revealed a better understanding of how they work. The second technique uses a separate EXE for running the long process while the main UI is completely responsive. I heard Steve won the award for the longest white paper at 200 pages, so we have plenty of material to help us with the implementation.

Refactoring Legacy Code
Paul Mrozowski

Dealing with legacy code has been a common theme throughout the conference, evidence that both speakers and attendees are having to deal with projects written by someone else. I enjoyed Paul’s approach to the material, not academic at all, but he still got the concepts across. I also appreciated the idea of taking small, low-risk steps to refactor the code, but making steady progress. As with other discussions on refactoring, there was emphasis on testing. Apparently, there is a whole discussion on “Unit Testing” vs. “Integration Testing”. Paul’s response: “I don’t care. Just test it.” My favorite quote of the session.

Bonus Session: VFPX Users Meeting

This session was well attended by both VFPX project managers/coordinators and users. There were several topics, but the main discussion centered around better deployment of VFPX files, and getting the word out to more Fox developers. You can watch the meeting at

Bonus Session: Stonefield Query Users Meeting

Doug Hennig puts together a meeting every year to show off new and upcoming features of Stonefield Query, as well as take requests. As an existing user, I like to go. This is awesome software, and the features coming in version 4.0 are going to make things SO much easier for our customers. If you have been considering a report writer, take a good look at Stonefield Query.

Club 709

The party continued at the Feltman’s for the second night and there were even more people this time. It was good to see YAG there. I met a lot of cool people and had some good discussions.