Hi Bonnie,

>I really wanted to stay out of this argument, but I thought I'd offer you a bit of advice. When you state things like this about .NET:

>>Prove it.... AFAIK, you cannot define a form class visually and subclass it visually just like in VFP.

It works diffently as pointed out by many (credible) persons up here, hence my comments. As I found out the details it requires some adjustment in code to do this. So to one extend the statment is correct you "cannot subclass it visually". You´ll have to do it in code after which you can work on it visually again.

>- and -

>>From all that I hear, this is the case ...

>... you are totally removing any credibility from anything you have to say about .NET.

No I´m not. Everythime I say something about .NET, I´m not sure of, I will say so (AFAIK, from all that I hear). If I´m sure I won´t use those statements. I´m sure about ADO.NET despite some people trying to shoot holes in my statments in e.g. saying that you can do SQL on ADO records sets by a SELECT() method (hhhhmmm, who is incorrect here?).

>You're relying on hearsay (from obviously not credible sources, I might add)

The source was credible, however, my intepreatation was somewhat incomplete (see above).

>when you really shouldn't make such statements unless you have personal practical experience with it yourself.

I beg to differ here. What you´re saying here is somewhat like CJ Date (Codd died last year) wrong when he says that SQL sucks while he never implemented a real world application. Or that an architect could not design buildings because he never actually build one. You´d better be carefull with such statements. A good database designer might have never build a database. A good software designer might never have build a software package in code.

If you look the other way arround. A good carpenter might not be able to design a good house. Simular a good coder might not be able to design a decent piece of software.

I think it is ignorant to think that you have to do some practicise before you´re able to judge. By looking at the characteristics of a tool at a higher level than just the implementation level, you can learn way, way more. If you really try to do this, you will see, despite the significant advantages in other areas, that .NET is lacking a solid native data handling.

And as I´ve learned over the years, about everything is about data. Why do you think that longhorn is going to run on database technology? It is as far as in the early 80´s or late 70´s that it was identified that an OS should just be a database. Now about 25 years later we´re going to see its first limited implementation.

The same applies to development tools. All resource regarding a projects are kept in the project manager. All classes and objects of those classes are kept in a classlib, All reportsobjects in a report file. All forms objects in a form files. IS THERE ANY REASON to abondon the idea to store this in a database ? In fact, many, if not all, ERP/ERM development tools do this exactly this way. Their data-engine drive the application. VFP has choosen quite a good storage mechanism for that as many resources are stored in tables, though I admit this could be even far better. By it structure, VFP is extremely well designed, a database that runs its applications as a database for a large part (no wonder it is still arround).

In this, with .NET we are taking a step back.

It will be interesting to see when MS will identify this Gap/Mistake and correct it.

>I will almost never reply to a post about something I haven't actually done.

Then you´re restricted to reply to very low level details. In fact you´re saying that you cannot talk about many subjects like "why a you´d better build a house out of bricks than out of wood" because you never done it. Simular you cannot not talk about software and application design. You would not know if you should make a device driver in dbase or C++. In real life, you´re not capable off much. If you´re not able to draw conclusions on speficications (of cars, houses, electronic devices, etc) you´ll not make it in this society. We all are able to make abstract models of real life situations and compare them. I don´t see why this is different in software engineering.

>I hate to come off looking like a fool if I don't know what I'm talking about.

Well, I do also, though others in this thread don´t mind. But if you clearly indicate that you don´t know, then you´re fine, even if someone if taking it up as argument in saying that you don´t know what you´re talking about: You clearly indicated it.

Walter,