Monday, September 10, 2007

VFP Runtimes - do we need an installer?

Years ago, the conventional wisdom was that you used an installer program to install the VFP runtimes on the user's machine and then possibly had an application update over it. On network applications (that resided on the file server), this was almost a requirement - the users couldn't run the application without the runtime - but you wanted to be able to install updates without requiring the user to upgrade their runtime files if necessary.

How necessary is that today?

In some instances, very. I still have some applications that reside directly on the file server, where is also where the data lies and thus having a separate runtime installer usually helps - but this can also be detrimental. Even with today's fast networks, the performance hits that come from running an application over the network instead of the local workstation can seriously infringe on the application.

The seeming hassle of creating a separate runtime for the application also strikes fear into some developers hearts as they have to (begrudingly, at times) admit their application uses FoxPro, which can affect how a company with a larger IT department might choose to support it.

This created a chorus of FoxPro developers wanting the VFP runtime to be included with the standard Windows install to make it easier for them to deploy their applications.

So as I was rereading past posts, I came across this great one from Calvin - Enable people to run your programs without installing anything.

It got me thinking - there was a time when a desktop install of 5MB was considered very large but those days are long past. With Windows Service Packs hitting up to 1GB and even the DotNet at 22MB, a 5MB install is nothing - I could install this online in less than 2 minutes.

As FoxPro developers, we are also used to putting files into their "proper" locations - "Common Files\Shared, etc, etc" as though there were lots of applications using the same runtimes. This could reduce versionitis, something that was supposed to be dealt with in XP and now Vista. But is this something that drastically affects VFP applications?

So, coming back to the post, Calvin's entire premise is to just zip up the VFP9R.DLL, VFP9RENU.DLL and the dreaded MSVCR71.DLL and put your application (or your application stub) right in there. Don't worry about pathing, just keep everything right in their own folder.

When combined with a program like Zip2EXE, which you can set to automatically unzip and then run a specific program, or even an installer such as InnoSetup, you can build an entire setup for your application (under 10MBs) that puts everything where VFP can find it without affecting other applications.

You may already be doing something like this so tell me, how do you handle installs?

Sunday, September 09, 2007

Tod blogs from FoxForward

Thank you Tod and added bonus - he's added his programs and presentation slides for Data Warehousing with VFP.

Looks like Kevin's put on another great FoxForward conference!




Tod means Fox | Live from FoxForward: In Alpharetta with My Mustang

Automating Builds in VFP

This is an older post but I was rereading it and realized I hadn't talked about it yet.

While VFP developers wait for tools (such as Solution Explorer (update: removed link - domain expired) or the VFP/X Automated Build client) , this post shows how to do it using a tool that

a) doesn't natively support FoxPro

b) integrates with the FoxPro environment using the VFP OLE Automation.


Yet another useful addendum to Tod's initial post



Kok Kiet's Blog : Experience in Automate VFP Project Build

Thursday, September 06, 2007

Cool Tool for Conferences

This should be updated for FoxForward as well but Dave Aring's great KokoPelli tool will certainly make scheduling conference sessions very easy.

Since it's in a DBC , it should be relatively easy to update for any conferences.

Great tool!

Shedding Some Light: Southwest Fox: K.O.K.O.P.E.L.L.I.

Powered by ScribeFire.

Converting XML to FoxPro tables


Many FoxPro developers are familiar with XMLTOCURSOR() which converts an XML file to a FoxPro cursor for review. This function works typically best with a single table in an XML file.

Unfortunately, it requires a fairly well structured XML file. For example, it can parse this XML perfectly:
<?xml version = "1.0" encoding="Windows-1252" standalone="yes"?>
<vines>
    <vine_lot>
        <id>1</id>
        <ripe_grape>4</ripe_grape>
    </vine_lot>
    <vine_lot>
        <id>2</id>
        <ripe_grape>3</ripe_grape>
    </vine_lot>
    <vine_lot>
        <id>3</id>
        <ripe_grape>3</ripe_grape>
    </vine_lot>
</vines>

Yet, it complains when trying to convert:
<?xml version = "1.0" encoding="Windows-1252" standalone="yes"?>
<vines>
     <Lot>
          <id>1</id>
           <ripe-grape>4</ripe-grape>
     </Lot>
     <Lot>
          <id>2</id>
           <ripe-grape>3</ripe-grape>
     </Lot>
     <Lot>
          <id>3</id>
           <ripe-grape>3</ripe-grape>
     </Lot>
</vines>

Now the reason may be obvious to FoxPro developers - (ripe-grape is not a valid field while ripe_grape is) - so clearly you have to be very careful when using XMLTOCURSOR.


This program (Advanced XML Converter) will take nested XML tables and create multiple DBF files with it (as well as other formats) - it also deals with these types of issues.

I tried it out because I'm always interested in handling different XML formats. I could likely transform a nested XML into a single one with an XSL but this seemed a little easier.

For those who are unsure what I mean by a nested table, here is a sample (borrowed from here):

<Vineyard>
      <Lot id="1">
           <ripe-grapes>4</ripe-grapes>
           <Picker>
                 <name>John</name>
                 <metabolism>2</metabolism>
                 <grape-wealth>20</grape-wealth>
           </Picker>
     </Lot>
<Vineyard>

In this scenario, you would see two tables: Lots and Pickers.

Advanced XML Converter saw this and when I saved it as "Vine" it created two DBF files: Vine_Lots and Vine_pickers.

Unfortunately, what it missed was the relationship between Lots and Pickers.

I would have expected to see an foreign key in Pickers that would link it back to Lot. Unfortunately, it missed this relationship. To get it to work properly, I had to do:

<Vineyard>
      <Lot id="1">
           <ripe-grapes>4</ripe-grapes>
           <Picker id="2">
               <lot>1</lot>
                 <name>John</name>
                 <metabolism>2</metabolism>
                 <grape-wealth>20</grape-wealth>
           </Picker>
     </Lot>

Which defeats the purpose of the nested XML.

It's too bad - because it did a great job in other areas. Still, might be worth a look if you're looking to at least see what's up with it.

Here's my list of ERs:
1) properly handle relationships
2) build an XSL that will do the conversion for you automatically

Of course, that's not necessarily its purpose - it's more for data crunchers but without the relationship support for nested XML, it is lacking it.

Do you know of a tool that can do this? (either from a command line or others)


Software can turn raw data into structured text., HiBase Group

Powered by ScribeFire.

Tuesday, September 04, 2007

Using VFP to fight crime and help police


Some FoxPro developers may be familiar with the WASP application that was featured as a Microsoft case study. Well, John Harvey has started coming back to his blog (FoxPro USA) and lets us know what he's been up to.

Best quote:
Most of the new development is supposed to be done in dot net, but
there's this thing called "get it done" or "just make it work, now".
So, enter VFP and Web Connection(thank you Rick Strahl).

What's very cool though is how little things are making a big difference and how easy it is for FoxPro to help do it.

Yes - any other tool could do it - but the point here is that you have a subject matter expert (John) combining his development tools to offer solutions that are of value to a large group of people.

Consulting companies often take the approach that things have to be complicated or very lengthy time-wise to build the best solution. This is where you hear end-users complain about "change requests" even for the smallest things (like changing a hotkey) - and then wonder where these companies get a bad rep.

Many times, it's the fast and simple approaches to solutions that make a huge difference.


Powered by ScribeFire.

Monday, September 03, 2007

Lost and Found Again: MindManager on the Pocket PC

Regular readers may know that I am a big fan of Mindjet's MindManager tool - I started using it after hearing about it being a killer application for the Tablet PC and then just wanted to use it for everything. Unfortunately the last version that had a real version for the Pocket PC was 2002. I'm now on the latest version (7) which totally rocks and had just finished sending a "when will you get a mobile version?" to the company when I bothered to look in the forums and sure enough, found a link to this little tool. Pocket Mindmap

It supports all of the key features and best yet, if you only have an older version of MindManager, it's compatible with that version as well.

I think everyone has done this in the past - complain about something and then when you scratch a little further, you find the solution  - I also appreciate it's a pet peeve for just about every company. I know I've seen it a lot in development forums where information is just about everywhere and nowhere all at once - but it's also in other areas as well (as I found out with this case).

Definitely a case of "look before you type"


Powered by ScribeFire.