Tod means Fox

Only a sleight deviation, I promise…I have a question for the spaces.live team. Why on earth can’t you get the headers right on these pages? Firefox can handle it, but I truly wonder what some older browsers do with this site. The W3C says this about this very page:

The MIME Media Type
(application/xhtml+xml) indicated parse mode should be XML, but the DOCTYPE Declaration indicates
SGML mode. Using XML mode based on the Content-Type header."


This is just one of 469 validation failures.

To make matters worse, this site also fails the Section 508 test (Google: “Cynthia Says”), which is designed for setting a minimum bar for accessibility standards.

OK… sorry. It’s not like my Blogger account fairs much better (but I think David Shae has some Standards-compliant templates in their somewhere…)

Ladies and gentlemen! Boys and girls! Step right up and watch the debate unfold. (Did you do the voice?)Most in the Fox community are frazzled by the grim reality of no more FoxPro releases. The folks at MasFoxPro are still trying to change Microsoft’s mind though, and I support them. Besides, if this works, I’ll hire them to get my 18 month old son to eat a little something more than just cookies and oatmeal (which he learned by watching me, of course).

Perhaps the best representation of the internal debate (and maybe a little in-fighting) is happening over at fox.wikis. Doug Hennig says that he will “move on and make the best of our situation”. While everyone is being forced to move on (at least to some degree, after all, VFP is a very mature language and will continue to be a valuable asset), some are slamming the door (and re-opening the door only to slam it again) while others are softly closing it.

Foxfolk, Milind Lele’s letter is posted at Microsoft.com. What I like about this letter is how he framed the decision to stop further development of VFP. Instead of Soma Somasegar’s comment about it being “hard to hear that you have to go and learn something else” (see my last entry), he focuses on addressing some of the concerns that VFP programmers are having about the announcement.

Here’s a taste:

Visual FoxPro core/engine is very stable. It has been so for a very long time. In fact, many have written to me asking, why this decision given such stability/maturity? One significant aspect to consider is this: Most of the feature enhancement requests we have received in recent years is XBase components. Thus making these components open source enables the community to drive improvements and enhancements and yet leverage a stable engine.

In this post I’ll show how you can use Beyond Compare’s scripting ability to compare DBFs from VFP.

“Your true value depends entirely on what you are compared with.”
Bob Wells

Occasionally there is a need to compare tables in two directories to make sure that they are the same (or different). You can use my Intersect example from my last post using VFP code, but this will only get you to the row. Additional code would be needed to identify the exact column that is different. Although this task is certainly possible in VFP, I thought that using Beyond Compare (BC) would be a nicer solution.

Not too long ago I found a way to ‘integrate’ BC from within VFP using BC’s script capability. It’s tough to find good documentation on how to do it, though. I’m all ears if anyone has a good reference. Anyway, the following code demonstrates how I was able to accomplish the task. The output is sent to an HTML file (which I thought was easiest to view/navigate).

LOCAL lcDirA, lcDirB, lcDisplayOption,;
    lcFileA, lcFileB, cVar As String
LOCAL ARRAY aDirA[1,1], aDirB[1,1]
LOCAL llDiffOnly AS Boolean
LOCAL n AS Integer
 
*-- step 1, get the directories
lcDirA = GETDIR()
lcDirB = GETDIR()
IF !DIRECTORY(lcDirA + "BC_A")
    MKDIR lcDirA + "BC_A"
ENDIF
IF !DIRECTORY(lcDirB + "BC_B")
    MKDIR lcDirB + "BC_B"
ENDIF
 
*-- step 2, load the tables into the array
lnDirA = ADIR(aDirA,lcDirA+"*.DBF")
lnDirB = ADIR(aDirB,lcDirB+"*.DBF")
 
*-- step 3, some options
llDiffOnly = .t. && set to .f. to display all records
lcDisplayOption = IIF(llDiffOnly,"display-mismatches","display-all")
 
*-- step 4, loop through the files that appear in both (the intersect)
FOR n = 1 TO lnDirA
     IF ASCAN(aDirB,aDirA[n,1]) > 0
        *-- copy to CSV (you will have to handle memo fields differently!)
        lcFileA = lcDirA+aDirA[n,1]
        USE (lcDirA+aDirA[n,1])
        COPY TO lcDirA + ADDBS("BC_A") + FORCEEXT(aDirA[n,1],"CSV") TYPE CSV
        USE IN (aDirA[n,1])
        lcFileB = lcDirB+aDirA[n,1]
        USE (lcFileB)
        COPY TO lcDirB + ADDBS("BC_B") + FORCEEXT(aDirA[n,1],"CSV") TYPE CSV
        USE IN (aDirA[n,1])
     ENDIF
NEXT
 
*-- Step 5, set up the script file
lcResultFile = FORCEEXT("c:tempBC_" + DTOC(DATE(),1) ,"HTM")
TEXT TO cVar NOSHOW
    load &lt;<lcdira+"bc_a">&gt; &lt;<lcdirb+"bc_b">&gt;;
    expand all
    select all.files
    option confirm:no-to-all
    file-report layout:side-by-side
    options:&lt;<lcdisplayoption>&gt;
    title:"&lt;&lt;_SCREEN.caption&gt;&gt;"
    output-to:&lt;<lcresultfile>&gt;
    output-options:html-color,wrap-none
ENDTEXT
 
STRTOFILE(TEXTMERGE(cVar),"c:tempbcvfp_script.txt")
 
*-- Step 6, Run Beyond Compare
RUN /N C:Program FilesBeyond Compare2bc2.exe @c:tempbcvfp_script.txt
</lcresultfile></lcdisplayoption></lcdirb+"bc_b"></lcdira+"bc_a">

Please note, that BC will open its own dialog that will display script, log,
and error information. I usually check the box ‘Close when finished’ so I have an idea when BC actually completed the task. Then I just browse to the HTML file created.

Of course, there is plenty of room for improvement in the above code. I’ve started a project to combine this with several other methods to do an exhaustive comparison of tables from one directory to another (which would include index, structure, and memo field comparisons). I hope to publish some of that code in upcoming blog entries.

Beyond Compare
A general scripting reference for BC

*Update*
It seems I always get bit by this: In my code example above, the HTML parser removed several chunks of code because they were in between < and >. I need to get into the habit of using the ISO-8859-1 character set codes instead. Blogger doesn’t convert these things for me… The code in the above example has been updated.

From the article “Microsoft Working to Broaden Reach of Its Development Tools“, over at Computerworld Development, Soma Somasegar, corporate vice president of the developer unit, spoke with Computerworld last week. Apparently Visual FoxPro developers are idiots who don’t want to go out and learn new things. While reality shows that Visual FoxPro developers are incredibly versatile, willing to adapt and learn new technologies, and quite capable of doing so. This guy Soma is insulting the Fox community, in my opinion. This is what he had to say:

It’s hard to hear that you have to go and learn something else. Some of these transitions have been smooth, others not so smooth. We want to be mindful that when transitions occur, there is a good reason and real customer benefit to them.

As if we’re being stubborn because we don’t want to learn. We’re being stubborn because Visual FoxPro is an awesome tool and many of us have built a career around it. We are stubborn because it will be even more difficult to sell a project in VFP. Soma needs a reality check.

Here is yet another article (a very well written and informative one, I might add) about MS’s latest announcement: Good News, Bad News for Visual FoxPro Developers by Stuart J. Johnston

Here’s a taste:

What makes VFP unique is that it closely binds a data-centric language with a local database engine, unlike any other developer tool,” says Ken Levy, a former VFP product manager. Because it was not directed towards the same markets as Access and Microsoft Office, the VFP product group was pretty much left to its own devices.

…

Through the years, FoxPro evolved into VFP, becoming another of the company’s “Visual” products, replete with integration into Visual Studio. But it was always somehow out of the mainstream. To some extent, that helped VFP establish a following that verges on cultish.