What's your wish list for VFP 10.0? 4

[dbMark]

What's on your wish list for Visual FoxPro 10.0? I know there are some request and wish lists on other sites (universalthread is one I can think of), but we've gotten so many great features in versions 8 and 9, what else is left to add? Tell the world here!

I'll start with a real biggie that's probably on your minds too...

Port Visual FoxPro to 64-bits! With Windows XP 64-bit edition already released to manufacturing and a 64-bit version of Windows Server 2003 in the works, it's clear that true 64-bit native functionality will quickly become the standard. Running VFP in Compatibility mode is okay for backward compatibility for a few years, but for VFP to have a strong and viable future, it must keep pace with this new architecture. It was dealt a blow when Microsoft excluded it from Visual Studio .NET, but I feel the port will be a crucial milestone that must be met.

If you think porting 64-bit is not an issue, how many 16-bit programs do you have that aren't considered outdated? That's because we've had 32-bit operating systems for about 10 years now and anything less is virtually ignored and considered as "legacy" program languages. Yes, I know they usually still work but usually with each new version of Windows more quirks and incompatibilities arise. The biggest concern is they aren't considered up-to-date anymore. Looking 3 years into the future, how many program designs and proposals do you think would get approved and aplications sold if VFP were still a 32-bit program? So a 64-bit port is critical to our survival!

Yes, I know the Visual FoxPro team hasn't said yet what's in store for version 10.0, but I for one wouldn't mind at all if the only major change or addition was a 64-bit port. Rah, rah, sis, boom, bah... for 64-bit!

Awaiting anxiously, dbMark

 

[robsuttonjr]

I would have to say that Microsoft's decision not to port to 64 bit basically seals FoxPro's end of life. They will for sure have some more releases to squeeze whatever last bits of revenue they can from the product. But rest assured that by not porting to 64 bit the products end of life is in sight. The fact that .NET will be ported and foxpro will not is just another sign of what lays ahead. So if you have not started learning .net, better get on it. You will likely be spending time converting Fox apps to .NET if not already doing so. If you have not already looked at the foxpro toolkit for .net, you should. It allows you to use many foxpro commands in .net. If you need anymore evidence of the dying breed we are go to yahoo hot jobs and search on foxpro vs .net jobs. You will clearly see the trend has been and is shifting to .NET. I am certain there will be Fox jobs for many years to come but they are few and far between. For those who work in a pure foxpro shop they have it easiest since they do not have to convince anyone. But for those of us working with Java and .Net programmers, we face scrutiny and are always have to prove FoxPro's validity. Any IT manager with a sense of technology will realize that the ole Fox has one paw out of the MS door.

Forums rule, pass it on!!!

Rob

 

[Mike Lewis]

Rob,

You might or might not be right -- I don't feel qualified to comment.

However, even if you are right, and VFP's fate is "sealed", it will still be around for many, many years.

After look, look at FoxPro for DOS, FPW 2.6 and Clipper. Those are all ancient products which have not been enhanced for around a decade. Yet there are still vast numbers of people programming in them. I feel sure VFP will survive at least that long, even after support has officially ceased.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[awaresoft]

Rob,

I have a different perspective on this 32 bit vs. 64 bit issue. If you look at the VFP runtime, you will notice that its based on the MS VC runtime which in turn is compiled with the latest Microsoft Studio 2003 C compiler. As Microsoft updates its runtimes, I can't see why the matching VFP runtime won't be upgraded as well. Remember, the VFP compiler does not need to generate 64 bit code. Only the runtime needs to change.

There's a long history of precedence for this going back to VFP 3.0 when Microsoft switched from the Watcom compiler to its own compiler. Since then, VFP has always shipped with the very latest version of the MS Visual C runtime.

Malcolm

 

[robsuttonjr]

There will always be some FoxPro programmers around. Perhaps til the day I die. However I do see that FoxPro is not the language of choice and in some cases is passed by when it is a perfect candidate whether knowingly or not. Simply accepting the fact that FoxPro is a product that will be end of lifed is not going to instantly put people out of work. However any FoxPro programmer that assumes they should stay with FoxPro exclusively may end up with the short end of the stick one day. If you are a 60 year old FoxPro programmer perhaps its ok. If you are a 20 or 30 something programmer, it is a good idea to be moving towards another language. Realizing where FoxPro is headed can help people better plan their future. Some of us have to consider the future and not all of us have the luxury deciding whether FoxPro will be the language of choice for our company. The bottom line is that we as programmers always have to be prepared to adapt and change as needed. However that is not to say we won't be able to enjoy programming in FoxPro exclusively for years to come. It is just going to get harder to find those jobs vs. easier with .Net or Java. The client server world is where its at for most apps and you don't have to have FoxPro's supper fast client side engine to accomplish tasks anymore. With the advances in pc technology we are able to accomplish all we need with thin clients and rich servers. Perhaps back in the day it made more sense to have a fast fat client apps which is FoxPro's forte. But anymore its not as important and is only an added bonus for those of us that use Fox. But looking at other ancient languages one knows there are always going to be jobs for just about any programming language. The key is how many jobs are available compared to the programmers seeking such jobs. Supply and demand are a factor here. 10 Foxpro jobs for a 1000 programmers is not a good ratio. I would rather be in demand as a programmer with 1000's of jobs for 1000's of programmers or some realistic ratio. I love FoxPro because thats what I know and use. But I am sure once I get .Net under my belt I will adjust and be that much more marketable. But with my current perspective, I will always prefer FoxPro over .Net simply for the love of the language. I would like to see a competition between .Net and FoxPro programmers. My opinion is that a FoxPro programmer can knock out an application much faster than a comparable .Net programmer. Perhaps more marketing and ROI push from Microsoft or some other source would help us out. But thats not going to happen. As it is we push forward programming for the love of the language and the bucks it provides. I will program in FoxPro as long as I can!

Forums rule, pass it on!!!

Rob

 

[craigsboyd]

awaresoft,

You make a very valid point. Those that would say that VFP will never be ported to 64-bit are saying that the language will languish and die when the world makes a majority move to this. While all languages will someday languish and die as they are want to do (who would have thought Visual Basic would become a dead language - ouch that had to hurt, especially for all those companies that were talked into porting their VFP apps to Visual Basic)... I am of the mind that 64-bit will not be the beginning of the end as it were.

Having said that, I am much more concerned about the possibility that .NET is. There have been some disconcerting comments by Ken Levy and others concerning Visual Studio 2005 and the future (for instance: whenever I've seen Ken asked about VFP10, he begins talking about Visual Studio). There are also a number of heavy hitters in the VFP Community, that for whatever reason have decided to pick up the .NET banner and run with it. They write .NET articles for VFP publications, create websites and companies (specifically designed to port VFP applications to .NET), and show up at VFP conventions with their .NET agendas (furthering the interests of .NET to any VFP Community member that will listen). I would wish them good luck in their endeavours, but I don't. I think they do a disservice to the VFP Community as a whole, and are biting the hand that has fed them so well for so long. How can I use .NET in conjunction with VFP to further my customer's applications and visions, sure. How can I replace VFP with .NET, get real. I ache for a Red Flag link everytime I see this type of thing, completely off-topic and of no benefit for a VFP Developer. Aren't there enough .NET conventions and publications that these types of discussions and articles would be better suited for? I don't look in VFP-based publications for articles that are solely on .NET anymore than I would look for articles solely on VFP in a .NET-based publication.

While I respect their right to an opinion as I hope they can respect mine, I don't agree with many of their present assertions. I am not disagreeing out of some blind love for VFP, but from experience in developing solutions in them both. I use .NET for what I have found .NET really excels at... mainly ASP.NET (with either C# or VB.NET code behinds). Similarly, I use VFP for what it excels at... mainly almost everything else. So, I hope that both .NET and VFP can live side by side (they are both wonderful at what they do well), and not be viewed/nor become competitors for the same market. Because anyone who has developed in both of them knows, though they are sometimes hard pressed to admit it, that neither does a good job at wholly replacing the other.

So my ultimate wish for VFP 10 is that there will be a VFP 10. And rest assured, myself and thousands of others will purchase it as soon as it is released.

http://www.sweetpotatosoftware.com

 

[pt777]

As an amateurish dedicated VFP programmer and physician (about 12 years) who has thankfully leached on to you VFP gurus (you know who you are), I really appreciate Craig's last statement, and Mike Lewis's (above).

More than once, I was told I needed to port to VB (before VFP COM commands redeemed everything).

I'm 48 and couldn't be more artistic thanks to the VFP medium with its COM capabilities, and API calls. I'm not about to learn NET, personally and professionally. That would destroy my holistic programming approach.

My wish list (So I wouldn't leach too much on you gurus):

1) More COM power and ease of use (with abundant help-examples).
2) More straitforward API power and documentation (with abundant help-examples).

Philip

 

[Nro]

At my opinion, I see VFP as a tool, a development environment. In one application, I’ll use Crystal Report, Outlook, some function from Excel, one or two reports in R&R, even some DLL compiled from VB 6 or VB.NET. I have some client using SQL Server or even MySql, and VFP can do the job.

You can do the same thing in .NET, except that it’s MS baby. A long time ago, when I first met Basic, with all these lines numbers, and GOTO, and GOSUB, it was Cheeswiz for me (I was programming in RPG and Assembler). Now I have some Expertise in VFP, try to understand .NET and still program VBA for Access (only for my wife’s projects...).

The wish I have (I think it’s a wish list after all) is a better installation program, à la .NET, to be able to get all theses DLL, dependency, and put it on one CD, ship it at the clients office, so he can install it, easily, with all the components

VFP is a great product, as always.

Nro

 

[awaresoft]

Nro,

> The wish I have (I think it’s a wish list after all) is a better installation program

Your wish got granted early! Check out the free InnoSetup setup builder at

http://innosetup.com.

This is a great tool for building easy to use but sophisticated setups. There's sample InnoSetup scripts for various versions of VFP on

http://fox.wikis.com.

Highly recommended.

Malcolm

 

[Nro]

Thanks Malcom.

I'll check this link this weekend.

Nro

 

[craigber]

Nro,

Have you looked at the Installshield Express that ships with VFP 9.0?

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[Nro]

Allo Craig and you all

I'm working with VFP 8.0 so far and I'm using a mix of InstallShield Express with VFP8.0 and VS6.0 'Package & Deployment Wizard'

I'm assumed that because it's not VFP, it will have little changes in Installshield. What I refer is the ability to analyze a VFP project to find all the dependencies, like Visual studio in 'Package & Deployment Wizard'. I still have to guess what are the DLL's, and include it in the InstallShield project.

For example, I have to install Crystal Report (8.5) runtimes with VS installer because it doesn’t want to register it automatically when I install with IntallShield. Maybe I’m wrong because I did not check VFP9 InstallShield, and maybe they include it. If so, I’ll run to get one copy.

But maybe I’m all wrong and have to learn how to use InstallShield Express better. But hey, it’s always better than Fox 2.6, ‘Setup Wizard’

Thanks

Nro

 

[craigber]

There are merge modules available for newer versions of Crystal Reports. In fact, with Crystal XI, only deployment via merge modules is supported.

VFP 9.0 has an updated InstalShied Express.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[Nro]

Allo

I know that I can distribute Crystal 10 and up via merges modules (and I do it for my customer with machines with Win2000 and up), but it was only an exemple. What is missing from installShield (at my opinion), is a true dependencies analyser so I don't have to care about DLL anymore.

I think we can start another thread with installation issues !

Thanks

Nro

 

[craigber]

Keep in mind that what ships with VFP is Installshield Express. It is a scaled down version of IS. The full version of IS does what you want.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[tamayok]

Overcoming the 2 GB table size limit is my TOP concern.

 

[MichaelKopljan]

Keep in mind that what ships with VFP is Installshield Express. It is a scaled down version of IS. The full version of IS does what you want.

VFP ships with Installshield Express limited edition (IS Express for Visual FoxPro). I have the full version of InstallShield Express 5 and there is dependencies tab with : Static Scanner, Dynamic Scanner and Import Visual Basic Project.

Michael Kopljan

 

[craigber]

tamayok,

The 2 Gig limit is not going to be changed. See

http://msdn.microsoft.com/vfoxpro/productinfo/faq/default.aspx

My suggestion is to put your ER's into things that could possibly make it into VFP.Next

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"