Perry,
Where does it say "To use Reporting services" dotnet is a must?
"WPF, WWF, WCF" what if I say I did use at least some of them w/o .Net (assuming you accept C++ and XAML as tools that could be used by VFP).
I mean "required dotnet" should more say "much easier with dotnet".
Cetin

>What is incorrect? To use Reporting services there is a dot net assembly you use. "WPF, WWF, WCF", get the dotnet download that will give you the necessary assemblies to support these features. VSTO is the only one of these technologies that is supportable in VFP, that I'm aware of. But some of these features would require a lot of coding.
>
>
>>Perry,
>>(still trying to keep away from these type of discussions:)
>>A little correction: "...requires dotnet" series is not very correct. OTOH not trivial for an average VFP user.
>>PS: I do love VFP,C#,SQL server and some others.
>>Cetin
>>
>>>A friend of mine loaned me a book on doing maintenance programming. The last chapter, the author talks about the IT industry. He discusses the need to stay current. And how all the excuses you will give just won't cut it.
>>>
>>>We now see everyday, options that are not available to the VFP programmer. Need to use SQL Reporting Services...requires dotnet, Interested in WPF, WWF, WCF....requires dotnet. Visual Studio Tools for Office lets you easily do some slick interfacing to Word and Excel...requires dotnet.
>>>
>>>And the comment ".NET is not ready for Fox developers", runs far deeper then what you were stating. Quite a few developers I've talked to at user groups, codecamps, etc. have experience with VFP. But they've moved on. I can assure you that in all the dotnet meetings I've attended in the last 2 years, not once has someone brought up that they just can't handle data correctly. Not once.
>>>
>>>I think from a consultant point of view, your doing your clients a disservice, if you can't offer them the capability of designing the software with state of the art tools.
>>>
>>>>Hi, Srdjan,
>>>>
>>>>To date, I've built about 10 .NET applications, and about half of them were VFP->.NET conversions. All but one use SQL Server/SQL Express as a back-end...one uses FoxPro tables as a back-end.
>>>>
>>>> 1. Time to get *comfortable* with NET.
>>>>
>>>>There's no one "right" answer. But in all but a few cases, it's more than 3 months. ;)
>>>>
>>>>I think much of it depends on the skill level of the person. If someone is a "sponge", if they can take a few hours reading and absorbing and processing magazine articles, blogs, and previous .NET solutions on the UT , they're going to pick up things faster than those who don't.
>>>>
>>>>I think HOW one learns .NET is as big a question as HOW LONG it takes. It's an investment as well as a cost.
>>>>
>>>>I also think those who have used VFP with other tools (another back-end DB, another reporting tool, XML, etc.) are at a general advantage over those who have only used VFP. That's not a blanket statement, but I think there's some truth to it.
>>>>
>>>>I'm not trying to be preachy (OK, not much, anyway ;), but several on this forum have given advice for many years to learn .NET before it becomes a big dot on their radar. Those who do so are at an advantage over those who don't spend time learning .NET until the requirement is staring them in the face.
>>>>
>>>>If the person is a PUTM member, search through all the solutions in the .NET forum of the UT. There's a ton of information up there. MSDN for VS2005 is (IMO) much better than it was for VS2003. Read CoDe magazine and get the back issues. Take a piece of your app and experiment with converting it. Again, go through the iterations as much as you can BEFORE the reality is staring you in the face.
>>>>
>>>>Everyone talks about learning C# (or VB.NET)...that's certainly a big part of it. But learn the capabilities of Generics and ADO.NET in VS2005 (and yes, keep a close eye on the LINQ project).
>>>>
>>>>Does this mean someone is going to put in some long nights? Sure. If we want to be treated with the same respect as other professions, that means investing time in one's career.
>>>>
>>>>2. Time to create your own, or adopt workable commercial framework (Not to someone like RickS, or BonnieB or meny respectable others, but to a regular senior level VFP person.)
>>>>
>>>>Some people can pick up a commercial framework and find themselves productive with it pretty quickly, and others can pick up a framework and really get bogged down. I've seen both happen.
>>>>
>>>>Even if you use a framework, you're still going to want to build a library of reusable components. Even the best frameworks don't do everything. The process of writing your own components will help with the learning curve.
>>>>
>>>>3. Time for conversion/development of typical VFP custom project. Let say, ordinary sales-invoicing application, involving standard reporting with some typical yearly/monhly/weekly/summary sales figures being derived
>>>>from the system and presented to the user. Client/Server app deployed on LAN.
>>>>
>>>>It depends on how well constructed the VFP application is. One of the many phases of a conversion project is to build a technical architecture definition - if the VFP app followed decent practices, that will help. If it doesn't, it many add time to the conversion process.
>>>>
>>>>Your asking good, though very general questions. I'm just trying to give some food for thought, based on what I've run into. If I can think of more later, I follow up.
>>>>
>>>>And finally....take the feedback of those who have not built anything in .NET for what it is - feedback from those who have not built anything in .NET. There's no question that .NET has a big learning curve. For some, the learning curve can't be justified business-wise. That's fine.
>>>>
>>>>But remember that the statement ".NET is not ready for Fox developers" is often translated as "I/we can't justify the time for .NET's learning curve". It's important to distinguish betewen the learning curve of a tool, and the capabilities of the tool.
>>>>
>>>>Kevin