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…
Debugging
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
loMyCOMObject.DoSomething()
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”)
Parallel.StartWorkers(“MyProc.prg”,,.t.)
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.