Yes, Rick, I've had the same situation as described in your post. (and I can certainly sympathize with your FoxPro Expert scenario)
I think it's because FoxPro 2.x and earlier was such a "power-user's" tool that many people who had dabbled with Lotus macros or dBase were able to create applications that did what was needed back when it was first built. But then that person left and no one knew how to update the "application", which, left without a name, was simply referred to as FoxPro.
I know of a few cases where applications run under the Development version of FoxPro, so they can make changes "on the fly".
Sadly, this impacts the "FoxPro" name in a fairly negative way. Every application has an identity , be it a sports pool or a mission critical application and when programmers don't give it that identity a name, simply referring to it as the tool used, then the repercussions can be greatly felt.
I know of several Excel or Word based templates that do all kinds of things but to the end users, it's simply "I create my template in Excel", without knowing that it's running 5 different macros and managing their entire operation.
With Office tools, the solution may be a bit easier to explain than with a developer tool like VFP. Maybe it's because the VFP splash screen always appears (I remember so many FoxPro 2.x windows apps where FoxPro was the first word people recognized).
And it's hard to explain to users that while, yes, FoxPro was the tool used to build the application, the original developer was so much out of his tree that he actually thought about packing the tables every time a form was exited (and Yes! I have seen that logic in older apps).
And now that VFP is an older application, and still known not just as Visual FoxPro but by the simpler "FoxPro" term, it may be too late to undo the damage caused by otherwise well-intentioned programmers.
But give your application a name - you had to name the APP file (hopefully you didn't call it just by MAIN.PRG) - give it an acronym , give it anything.
Even if it's just the "Customer Maintenance" - or an acronym - I once built a system known as the WIS (pronounced Wiz) - Warranty Information System - as well as worked on something named CATS. While many users may recognize that they are working with a FoxPro application, they learn to treat the application as an identity. (how many VB apps have you heard of referred to simply as "VB"? - Access on the other hand, has the same issue - Q: what's your application called? A: oh, it's Access)
Imagine what would happen if all cars were just known as "car". Well , I guess it happens in some cases, where people generalize by saying "All Fords are _____" or "all Toyotas are _____". But with computer applications, even giving something a code name gives it an identity. FoxPro has a long tradition of great names but developers would do well to put their own individual stamp on each application they build, be it a minor revision or a major triumph.
The idea of a code name isn't always documented but it is important. (note that it is not the ONLY essential thing - I've seen developers jump on the MSF bandwagon, give their project a codename and then expect everything else to follow suit - BAD IDEA).
As FoxPro developers, we will have to face the likely painful legacy caused by those who did not give their application an identity,and in doing so, created the scenario that Rick so well describes in his post.
Shedding Some Light: 06/01/2005 - 06/30/2005
I think it's because FoxPro 2.x and earlier was such a "power-user's" tool that many people who had dabbled with Lotus macros or dBase were able to create applications that did what was needed back when it was first built. But then that person left and no one knew how to update the "application", which, left without a name, was simply referred to as FoxPro.
I know of a few cases where applications run under the Development version of FoxPro, so they can make changes "on the fly".
Sadly, this impacts the "FoxPro" name in a fairly negative way. Every application has an identity , be it a sports pool or a mission critical application and when programmers don't give it that identity a name, simply referring to it as the tool used, then the repercussions can be greatly felt.
I know of several Excel or Word based templates that do all kinds of things but to the end users, it's simply "I create my template in Excel", without knowing that it's running 5 different macros and managing their entire operation.
With Office tools, the solution may be a bit easier to explain than with a developer tool like VFP. Maybe it's because the VFP splash screen always appears (I remember so many FoxPro 2.x windows apps where FoxPro was the first word people recognized).
And it's hard to explain to users that while, yes, FoxPro was the tool used to build the application, the original developer was so much out of his tree that he actually thought about packing the tables every time a form was exited (and Yes! I have seen that logic in older apps).
And now that VFP is an older application, and still known not just as Visual FoxPro but by the simpler "FoxPro" term, it may be too late to undo the damage caused by otherwise well-intentioned programmers.
But give your application a name - you had to name the APP file (hopefully you didn't call it just by MAIN.PRG) - give it an acronym , give it anything.
Even if it's just the "Customer Maintenance" - or an acronym - I once built a system known as the WIS (pronounced Wiz) - Warranty Information System - as well as worked on something named CATS. While many users may recognize that they are working with a FoxPro application, they learn to treat the application as an identity. (how many VB apps have you heard of referred to simply as "VB"? - Access on the other hand, has the same issue - Q: what's your application called? A: oh, it's Access)
Imagine what would happen if all cars were just known as "car". Well , I guess it happens in some cases, where people generalize by saying "All Fords are _____" or "all Toyotas are _____". But with computer applications, even giving something a code name gives it an identity. FoxPro has a long tradition of great names but developers would do well to put their own individual stamp on each application they build, be it a minor revision or a major triumph.
The idea of a code name isn't always documented but it is important. (note that it is not the ONLY essential thing - I've seen developers jump on the MSF bandwagon, give their project a codename and then expect everything else to follow suit - BAD IDEA).
As FoxPro developers, we will have to face the likely painful legacy caused by those who did not give their application an identity,and in doing so, created the scenario that Rick so well describes in his post.
Shedding Some Light: 06/01/2005 - 06/30/2005
Comments