Bo,

Good post. I agree with you on most points here. Not sure about the multi threading. Data validation already happens in our application while your working with it. It all is in the same thread, and I don't see the need of a seperate thread to it as most validations can be done very quickly (with the help of validation - metadata and eval() and EXECSCRIPT() functions) and done instantanious.

Also execute asynchonous queries is not anymore difficult than in .NET anyways. Long processes (we don't really have them anyways) are done out of the main application process anyways. We currently are designing a server service for taking care of certain maintenance tasks that might be executing longer processes.

We do provide spellchecking in our applications, but since we're using the native VFP editbox, it needs to be invoked explicitely. No realtime validation. To be honest never thought about that one though.... It probably needs to be replaced by some activeX control to provide this. This indeed the weak area of VFP. Its native GUI. Fortunately there are loads of activeX controls that provide addition functionality.

And BTW, indeed my point is that both tools are different animals. Depending on what you do, one might fit your goals better than the other.

That being said, there is no doubt that .NET is improving. From a data handling pov, it is getting much better than the initial release of .NET. LINQ, IMO has taken a big step towards handling data better and from a more abstractional pov (more like 4GL: more defining what has to be done, rather than how it should be done).

Personally, I'm not a fan of strict typed languages. You're spending a lot of time on dealing with type definitions, esspecially on cases where it becomes cubersome (late COM binding, type casting SQL results from on the fly create SQL). I'd rather see dynamic typed languages equiped with optional type checking with is done real time in the editior rather than on compile time only.

Lets see what the DLR has to offer within a few years time.

Walter,





>
>I posted those examples not because they are impossible in VFP, they are all possible, just more painful in VFP compared to other languages. In the same way as your example is not impossible in .NET, but requires more code to do the same thing in .NET compared to VFP.
>
>I went to an MSDN event a few years ago and the topic was about some new class that MS had posted for .NET. Everyone was super excited. Even the presenter could hardly contain himself as he went through the hundreds of lines of code in this new class. He went on and on about how cool, exciting and innovative this new class was. About halfway through the session, I leaned over to my friend and said: "Dude, can't we already do this in VFP in like 4 lines of code?". But now, because of this class, .NET developers can do the same thing in 4 or 5 lines of code using this class. And there are many, many more classes available and coming out for .NET all the time.
>
>As far as the usefullness or importance of threads. I think they are very important to a database developer. Especially one who wants to build World Class applications into the future. Making a user wait for even a semi-long running process to finish before they can do anything else in your app these days is as bad as making all your forms modal was 10 years ago. Even low end PCs now come with multiple processors (or at least simulate it). Without threading, you will never be able to take full advantage of the users hardware, when you need to.
>
>There are many, many more uses for threading than I can mention here, but my favorite example is the spell checker in Word. You are typing in one thread while the spell checker is validating your data entry in the background. How nice is it that you get a little squigly under a missspelled word, as you type without slowing you down, but very informative.
>
>Comapare this to how most data entry forms work....you would either get a warning dialog with every misspelled word you typed or not know you misspelled a word till you hit the save button. But somehow most data entry forms are this way and users either don't like it or have just accepted it.
>
>Comparing VFP to .NET is like comparing a 1978 Pontic 6.6 litre Trans Am (with a trailer hitch) to a 2004 Lincoln Navigator. Both of them can get you from point A to point B. But depending on what you are doing, one of them is going to kick the others butt and one of them is going to become more useful than the other as time goes on. (FWIW, I drive my Trans Am as often as I can)
>
>
>>Great if that is any use to you. I know there are ways to do multithreading in VFP somehow, but lets be realistic. What use is this to me as a database developper ? I don't need to spawn extra threads in my application. If I need to do things in parrallel I'd probably can do with server COM solutions or launch another process (EXE). Not as clean as with the thing mentioned above, but it would do. Not that I've used this in any commercial app BTW. There simply was no need to.
>>
>>In regards to passing a variable of complex type or structure. Oh we've done it in the past to overcome some limitations in VFP. Cristofs struct class is one way of dealing with it. In regards to callback functions. Do you mean events? You can capture them with VFP9 BINDEVENT() function. Lets not forget that VFP9 is extensible through flls. In the past I've written flls to do things that were not posible through native VFP.