> I'm curious how many people in this newsgroup program in Visual FoxPro.

> I've only touched on VB and I lurk here with the hopes of picking up
> something useful along the way.  I don't think it's too unusual these days to
> find developers using more than one tool for development.

>I've only touched on VB and I lurk here with the hopes of picking up
>something useful along the way.  I don't think it's too unusual these days
to
>find developers using more than one tool for development.

>Greg

>> I'm curious how many people in this newsgroup program in Visual FoxPro.

>--
>Become a member of the FoxShare Mailing List
>http://www.hourglassconsulting.com/whyted/default.asp?cTable=foxShare

> > I've been into Foxpro for Windows (2.6) and other xbase apps for quite awhile,
> > but i'm just climbing the learning curve for VFP 6.0 and OOP now.

> > I've only touched on VB and I lurk here with the hopes of picking up
> > something useful along the way.  I don't think it's too unusual these days to
> > find developers using more than one tool for development.

> Well, no. I'm more or less in the same position as you, but I'm not about
> to write a front end in VFP. Too much of a hassle. Use VFP for the
> database, by all means, but VB will leave your options open for other data
> sources.

>Andriy Luchkovsky

> > What data sources can you access with VB that you can't from VFP?
> > What do you consider to be a hassle for writing front ends in VFP?
> > Would you also use VB as a front end to VFP data instead of VFP itself?

> > I'm asking seriously.  Not trolling to start a "who's got the better tool"
> > war.  I want to use the best tools for specific jobs and I certainly won't
> > tie myself down to one tool for all jobs.

> > You know: When the only tool you have is a hammer, all problems become nails.

> <grin> noted. To address your points -- VFP will access the same data
> sources as VB. No problem there.

> My beef with VFP is the language. It's a mass of patches as Vulcan evolved
> into dBase to FoxBase to FoxPro to Visual Foxpro.

> I'm asking seriously.  Not trolling to start a "who's got the better tool"
> war.  I want to use the best tools for specific jobs and I certainly won't
> tie myself down to one tool for all jobs.

> You know: When the only tool you have is a hammer, all problems become nails.

> Like many of the posts, I went from FP2.6 to VB, instead of VFP.
> Considered not only the learning curve, but what resources were
> available: books, courses etc.
> At the local book store there is a wall of VB books and only on
> Microsoft Reference for VFP 5.0! Nobody around taught VFP.

> Main problems I have experienced with VB is:

> 1)  When editing a datasource you can jump right onto the data fields.

> In FP 2.6 you had to hit edit, and then were given a Cancel button to
> back up of the edits. This relates to the scatter/gather commands.

> 2) Formatting text boxes has been a nightmare - try to display and
> edit a textbox (or any other box) using $##.## right justified.

<snip>

> VB, however, is still recognisably the Basic I learnt on a TRS-80. Shorn of
> line numbers and with subroutines evolved into procedures, all of the good
> gear is "under the bonnet" with the MyData.MyElement.MyProperty.MyMethod
> sort of syntax.

> Fine if all languages were created equal, and all programmers likewise. Out
> in the real world, projects get worked on by many programmers from many
> backgrounds, and many different levels of skill. Ever try to maintain C++
> code written by a few different programmers? Do the same with VB code and
> it's a lot easier.

> > Yup. And I like that too.

> Now, if you want an elegant language that does this sort of stuff, have a
> look at AppleScript. It has shitloads of elegance.

> Pity that it doesn't have the user base.

> > I still think this is subjective to taste and experience.

> Indeed. But I'm an xBase programmer from way back, and after discovering
> VB, I don't care if I never code another line in FoxPro.

> You too. I really shouldn't be so argumentative. I spend most of my on-line
> time in a politics group where it's taken for granted that the other guy's
> opinions are a long way from yours and very strongly held.

> > > What data sources can you access with VB that you can't from VFP?
> > > What do you consider to be a hassle for writing front ends in VFP?
> > > Would you also use VB as a front end to VFP data instead of VFP itself?

> > > I'm asking seriously.  Not trolling to start a "who's got the better tool"
> > > war.  I want to use the best tools for specific jobs and I certainly won't
> > > tie myself down to one tool for all jobs.

> > > You know: When the only tool you have is a hammer, all problems become nails.

> > <grin> noted. To address your points -- VFP will access the same data
> > sources as VB. No problem there.

> > My beef with VFP is the language. It's a mass of patches as Vulcan evolved
> > into dBase to FoxBase to FoxPro to Visual Foxpro.

> Actually, VFP 6.0 has about as much in common with it's ancestors as VB 6.0
> has with basic 1.0.

> > There's very little integrity and elegance to it.

> I personally think integrity and elegance really boil down to the
> programmer, not the language.

> > Fine, if you have a career tied up in understanding the ins and outs of it,
> > but when you have to share with other programmers, then maintenance becomes
> > a major hassle.

> Hire the right people. <g>

> > And yes, I would use VB as a front end to VFP data. That's the essence of
> > the system. It's not a database, it's not a word processor, it's not a web
> > browser, but it can control all of those things, using the same language
> > and syntax.

> Yup. And I like that too.

> I still think this is subjective to taste and experience.

> > To continue your hammer metaphor, using VFP is like using a hammer
> > yourself. Using VB is like getting someone else to use the hammer. If the
> > speed and result is the same, then what's the problem?

> No problem at all.  Like I said, the right tool for the job is not always
> the same tool.  If I can become as proficient in VB as I am (or will become)
> in VFP then it becomes a usable option for me.  That's why I'm here. :)

> > Using your logic, we might as well not use VB at all, because every other
> > program is purpose built for what they do. Why on earth should we use VB to
> > open up a web browser when any fool can go and click on IE for themselves?

> I certainly wouldn't go (and haven't gone) that far.
> My point was actually that we should stay as diverse as possible.
> Our marketability goes up when we know both (and other languages as well).

> It's nice talking to ya.

>I think you've made my point for me.

>VB, however, is still recognisably the Basic I learnt on a TRS-80. Shorn of
>line numbers and with subroutines evolved into procedures, all of the good
>gear is "under the bonnet" with the MyData.MyElement.MyProperty.MyMethod
>sort of syntax.

>Like many of the posts, I went from FP2.6 to VB, instead of VFP.
>Considered not only the learning curve, but what resources were
>available: books, courses etc.
>At the local book store there is a wall of VB books and only on
>Microsoft Reference for VFP 5.0! Nobody around taught VFP.

>Main problems I have experienced with VB is:

>1)  When editing a datasource you can jump right onto the data fields.

>In FP 2.6 you had to hit edit, and then were given a Cancel button to
>back up of the edits. This relates to the scatter/gather commands.

>2) Formatting text boxes has been a nightmare - try to display and
>edit a textbox (or any other box) using $##.## right justified.

>Later,

>Strops.

>>I'm curious how many people in this newsgroup program in Visual FoxPro.

>>Andriy Luchkovsky