Why switch to VFP?

[ArevProgrammer]

Hello,

Given the nature of the Windows O/S and it's inherent nature to crash because of whatever reason, why is it important to switch to VFP? There are hundreds, if not thousands of DOS applications still running. And, if Win XP
still supports or emulates DOS, then whats the rush?

There are things in Foxpro 2.6a DOS that I can do in my
apps now that I cannot do in VFP (easily). I'm not saying I
don't like VFP, because I have VFP 7.0. I just want some feedback from you guys here in the forum.

Thanks,

Scott Rome was not built in a day. Be patient!

 

[kurtje]

well, thts an easy one for me ....

1° When we are buying a computer to put our program on it they are all preinstalled with windows xp or win2000 on it.

2° If the user want xp or win2000 installed on his computer then well we have to give him a xp or win2000 computer.

3° We have a lot of other appl tht r working on our computers and sometimes they require win2000.

;o) so it is not only we tht decide witch os we are going to install but the user and the supplier

 

[rgbean]

Scott,
DOS apps and FPD apps in particular do not all work well on Win2K or XP. I'm curious about what you can do in FPD that you can't do (easily) in VFP?

Once you spent some time in VFP (I've got ~7 years in it!), and you've learned or developed a framework, almost anything is possible. One thing you never had in DOS is access to the whole WinAPI, and now with automation, VFP apps don't have to even look or feel like xBase. (We've been working on some apps that you'd never guess were written in VFP.)

Rick

 

[GriffMG]

Why hide then VFP?
Personally, I program in VFP and Clipper quite a lot. The DOS environment is better for data entry - the windows GUI is good (and getting better) but if you have a lot of data to enter, the DOS route can be quite a lot faster.

BUT... the VFP environment is ace, I really get a buzz from making apps in it and I can do some things in VFP that I couldn't do in Clipper...

Oh, but then again... I do have one app that will be very difficult to replace with a windows front end, but the cost will be immense - because the DOS stuff is SO FAST...

Regards

Griff
Keep [Smile]ing

 

[infinitelo]

This question comes up a lot ie to switch or not to switch.

I think the key point is where you are at in your developement cycle. If your using all new pc's and delveloping new processing the vfp solution offers better and more wizards/tools/wigets plus smoother compatibility with other microsoft products.

but... if you have thousands of lines of code that have been working smoothly for five or ten years why switch just to be on the bleeding edge.

if its not broke don't fix it.

 

[Scott24x7]

Scott,

>Given the nature of the Windows O/S and it's inherent
>nature to crash because of whatever reason, why is it
>important to switch to VFP?

Well, first, I've actually not heard the argument of Windows stability/instability as a reason to "Move" to VFP. I would carefully consider what it is that you want out of VFP that you can/can't get out of your older version of Fox.

>There are hundreds, if not thousands of DOS applications
>still running. And, if Win XP still supports or emulates
>DOS, then whats the rush?

There may, or may not be legitamet reasons for this. True, there are many FP2.6 DOS/Win apps running, and running just fine. The key here is, is there some feature/function that you either have to do a LOT of work around, or can't do at all in your current version that you want to do? If yes, move to VFP. If you have a client that is "Complainging" that their app doesn't look and feel like "Other" windows apps, then again, it may be a good time to move to VFP. As for RUSH, that's an intersting term... since VFP has been around since 1994, I hardly think if you are just now considering a move to VFP that it's a "Mad dash" to migrate to the latest tool. Yes, you may have some catching up to do...


>There are things in Foxpro 2.6a DOS that I can do in my
>apps now that I cannot do in VFP (easily). I'm not
>saying I don't like VFP, because I have VFP 7.0. I just
>want some feedback from you guys here in the forum.

I would challenge you (in a positive way) to illustarte what can be done in 2.6 for DOS that is *difficult* to do in VFP. Do you find it difficult to do in VFP because VFP does *it* differntly? That does not necessarily mean that it is difficult, it just means you have to learn a new way of "Doing" it in VFP.

Having just made a leap to VFP 7 from 2.6 myself (only in the last 2 months), I know that I certainly thought that the concept of Table and Row buffereing vs. SCATTER/Gather, and SHOW GETS routines, was much easier in 2.6 than in VFP. However, now 2 months later, I am AMAZED at the things that I can do, with so much less work, especially when it comes to modifing data in tables. TableUpdate and TableRevert are a God send, by comparison, and once you "Get" how they work, you will find it is much easier than it ever was before. (I would say, for me, this concept was actually my biggest barier. Once I crossed it, I knew I will never create a "New" app in a version prior to VFP.
Will you need to spend some time learning new concepts? Yes. Will you need to spend some time converting some "old code"? Yes. Will you be light-years ahead in only a few weeks? Yes. If you've got the time, make the investment. I would recommend getting an interactive traning course. I bought AppDev's VFP 11cd course, for only $600 USD, and spent 2 weeks covering the material, on a "Part time" basis. (I could have gone through it in 3 or 4 days, had I spent all my time with it...) In my spare time at night, after work, and on a couple of week ends, and I had a great foundation that I started working off of, and could see results immediatly. There are other good one's out there as well, heck, even check e-bay and buy one cheap second hand. (I think Keystone makes a good one as well. There are 3 or 4).
I have a number of older apps that I continue to support in DOS and Windows 2.6 versions. But anything new I create, I'm making in VFP. You will especially bennifit from the standardization, and more advanced features that make VFP apps feel more like professional Windows apps. With things like native Drag-n-Drop, and OLEdrag-n-drop, along with support for ActiveX, it is LEAPS beyond 2.6. (And believe me, I LOVE 2.6, but VFP is so much more rich). Try putting a Rich Text control in a 2.6 application. Can't be done. Try using Drag & Drop to move pictures from one object to another in 2.6. Can't be done. If your client's need this type of functionality, 2.6 can't deliver it. You then have to move somewhere... that could be VFP, or some other tool, but your leap to VFP will be a much shorter one.

I guess that's my 2 cents... I hope I've provided some help.

Best Regards,
Scott

Please let me know if this has helped

 

[xBaseDude]

I'm an old fart, and ran this dialog with myself when FPW came out, if I can do it in FPD, why the heck should I worry about FPW26. It was running on a 16mhz machine with 4meg ram, under Win311. Windoze we use to joke. Until I got into it. I was immediately amazed at how much my FPD26 background worked almost seemlessly in the FPW environment. Pluse I had much more control over the screen display, and user interface.

I was apprehensive about moving to VFP, but my first experience with VFP50 was a good one. I agree that it is not easy to move 26 screens into the VFP environment, but 26 PRG files do run seemlessly. (A simple horizontal rule, will totally trash the VFP import process on 26 screens.)

The OOP priciples in VFP seem no different than the PROC files in 26, and are real time savers for RAD. Tying into the win api is another definate plus. Your background in 26 will definately give you a leg-up in getting into VFP.

The fact we are still discussing a program that is almost 10 years old, shows how much foresight the original programmers of 26 had. SQL code *years* ahead of the current client-server craze, when file-servers over 10meg Ethernet were the trend. Netware in it's infancy. Row and File locking. DDE and simple OLE *great stuff*

The sad thing is, this most excellant program never got the support from MS it should of. Since Bill grew up coding in Basic, it will probably always be a Basic oriented world coming out of Redmond. Even my favorite xBase author Miriam Liskin, has now sold out and is tooting VB as the "new" bigga thing.

Career wise, it's probably a bad move to invest exclusively in VFP without also learning VB. Instead of the question being why move from FPD to VFP, it should probably be why move from FPD to VB.

Just running my fingers....Wayne

 

[Utpal]

I agree with xBaseDude. I have been developing in FoxPro 2.6 Windows & DOS and Clipper to some extent since 7 years. I have developed quite a many applications using them and still do to some extent. But since 2 years I have been developing all my new applications in VB 6.0 - Access 97 and at present VB 6.0 - SQL Server 7.0. The difference lies not only in the availability of many controls and interfaces to the windows environment, but also in database security, consistency, tolerance and network efficiency especially with a large number of concurrent users.
In RDBMS you can :
* ensure data consistency by defining constraints to maintain entity integrity (uniqueness of code) and referential integrity (consistency of relationships between tables).
* define database triggers and stored procedures which carry out many database updation routines at the server, which is more efficient than doing all those jobs from the front end, because of reduction of the number of round-trips to the server.
* maintain user - password security, so that no unauthorised person can tamper with the database.
* have more crash tolerance. e.g. when there is a power cut.
There are many more other things than these. I have just told the ones that came to my mind.
VFP can also connect to RDBMS databases, but not as flexible and vast in scope as VB. In terms of flexibility, one big thing that matters to me a lot is the scrollbar control, which is there in VB but not in VFP. I need the scrollbar control in a master - detail form, to create the detail grid. The readymade grid controls are not advisable to be used because they have to be bound to the tables, which creates record locking problems in a network.
I gave you the best of knowledge I could give. There maybe still many other things which I may not know.

 

[finsys]

Not wanting to start a VFP/VB war, but....

"VFP can also connect to RDBMS databases, but not as flexible and vast in scope as VB"

VFP can connect to ANY database backend that VB can. You can use ADO, ODBC, anything you use in VB can be used in VFP. And since VFP is a database programming language, it's WAY more flexible at manipulating the data than any program you'll ever create in VB. I'm currently working on a project that uses SQL backend with VFP front end and after the initial hurdle of learning to interact with SQL Server, I'm developing just as fast as when using VFP tables/dbc's. I've used VB for data access and it just doesn't compare.

On the thread topic, I agree with the "if it ain't broke, don't fix it" already mentioned. At my last company, I wrote a DB in DOS Fox2.6 10 years ago. Despite a failed attempt to "supercede" it with a VB/SQL solution (at a cost of £250,000!!!), it is still going strong because it WORKS. But any new projects I use VFP7. New users are used to Windows and expect Windows functionilty, VFP gives that over Fox2.6.