Hi stephen,

>>>>I'm still waiting on Microsoft to announce a new development platform where RAD and Database integration has the foremost priority. From my idealogical standpoint this is the wave of the future. I'd like to promote the sentence: "Every application wants to be a database application when it grow" to "Every development tool wants to be a database tool when it grows up". .NET in any way you put it does not fit the bill. I'd rather wait for the announcement of the tool (Microsoft has some research projects going on that are more data centric), than hastly jump the wrong ship. I'd rather jump once into the right ship.

>RAD is a bad acronym. Rapid Development is usualy bad in the end. Not enough time was done in requirements gathering, Anaylists didn't dig deep enough to get to questions that needed to be answered. Instead they saw visions in their heads that 1) This is a simple app. 2) It's just a few forms and a couple of reports. 3)They don't really need anything more.

What you are referring to is not RAD, but rather prototyping IMO. To me RAD is doing the things you have to without having to think too much about the implementation. This means that the most common tasks should be done as easy as possible: IOW,:
- Dropping a table, grid, field, combobox on the form, asking for the most common properties and go.
- Having wizards to perform common tasks
- If you have to write some additional code, it should be as few lines as possible
- Powerfull debugging options, AD Hoc problem solving (Browsing tables or resultsets).
- On line development (Develop while the application is in production environment)
- Powerfull DML (Just like VFP) for both local and remote data.
- Powerfull RAD reporting options

But also

- Defining the formal desing of the database (ER, NIAM), tiers, layers and object relations.
- Self documentation of objects (application and database structure)

Whether you did a thourough analysis or not does not have anything to do with RAD IMO

>I have been striving hard at making my biz logic first without ever dealing with an interface. If I can unit test at this level it matters not if it's web/win/WS. It just works.

The implementation of anything need a good thought. Whether you begin at your biz logic or on the GUI might be just a matter of taste. Of course the final interface between the two should be done after the former two. The GUI and BizObjects in fact should be decoupled as much as possible anyways.

>VFP Developers IMO tend to see the app through the interface. They visualize forms with buttons and controls for display / editing. It's kind of like they are blind and they can see by feeling. This isn't a put down, but I have woked with teams in java/xml, VB, and VFP. The VFP developers take the most shortcuts of of the lot.

You might be very wrong on this. Defining the GUI is one of the most important things in software development because this is how the user experiences its software. If your biz objects do determine your GUI or the other way arround, I think you've got a wrong idea about creating layered designs: They should be totally independed from eachother.

>Do you design by test? At the pre-set of a code phase, do you know what the manager expects for sign-off on this module?

No I design by problem, Meaning that I solve the problem by taking a stack of paper and a pencil (Or sometimes drawing electronically) and draw GUIs, talk this through with the client (if neccesary) to determine if we can solve the problems this way. Only after approval we begin to desing the actual GUI. IOW not starting in the wild. The logical problem should define the GUI, not the technical implementation.

>>>hahahaha. Not ever tool plays well with others. .NET does a great job in attempting to deliver on that line. VFP can't, wont and that will be it's final pox.
>>
>>Where ever did I say this ?? I'm just awaiting new technology that more fits into my perception of the future. More the like of ERP/ERM systems with e.g. .NET integration (MBF), or an significant upgrade to their aquired Navision. IOW, more database oriented development platforms. Something that .NET currently is rather weak in. Therefore I'm waiting for the next generation of database driven technology. It is my pov that the single .NET platform is not there (yet).
>
>Ok, Your waiting for another fourth gen language to take over the world? I know another new one will come along and it will replace C# for me. Which replaced VFP, which replaced Basic, ...

I'm waiting for a new 5th gen language. BTW, C# is not a replacement of VFP: They are very different animals, nor do I see VFP as a replacement of Basic. VFP is data driven, the other two are not. And no, I'm not specifically waiting for a replacement of C#, I'm waiting for new technology that handles and integrates data much better than VFP does now currently, not even to mention .NET. But this does not mean that this tool cannot be based on enhanced .NET technology.

>Ok, what is it that VFP can do so easily and all other OOP's can't grasp. I'm always looking for true differences myself.

Data, Data, Data. In VFP you can easily work with data in many aspects: Do SQL or Xbase DML on local database sets, datamunging, data analysis. .NET and other OO (non database) languages fail in two ways.

- They fail to handle application (locally) held data relationally (having a reasonable DML)
- They hold data in process memory, therefore hogging it when holding large quantities of data.

In .NET, you're way more depended on the backend to do your data. On the client, you'll have to deal with collections to handle your data, which has all kinds of implications that are not ideal in many ways. Collections of data SHOULD be handled relationally, not by mannually going through collections.

>>>.NET is great at the little stuff. Like making a picker dialouge that will showcase images instead of details or plain file names. When you get to the nitty gritty VFP won't ever do it and you only have to roll your own each and every time.

Are you sure about that ?? What prohibits me in building a class or using the win API or ActiveX control to do the same ? This is not the exclusive area of .NET IMO ?

>I'm not building the control, just enhancing what is out of the box with .NET. I'm creating a picture(s) / movie tab to an inventory form. This app is for selling BIG Trucks, tractors, heavy equipment at auction. User wants to create eBay sales for stuff that doesn't sell localy. So I have to grab 5+ images for the truck. We shoot a 30 second video where the salesman over the asset shoots the footage, and talks about what the truck is. This is in a pilot phase now so we are seeing if it will reduce the # of emails about the asset. 1 freightliner listing can generate close to 100 emails from people all over. We are going to list the move off of our site starting next week.

Capturing, selecting images and videos is something we already have done in an VFP application with the help of LEADTOOLS and PEGASUS ActiveX controls. I'm not saying that it was painless, but certainly doable.

Walter,