Sivain,

>>I have the opinion that VFP is a very fine language because most things (aside from OOP) are straightforward, easy to understand and allow us to write maintainable code rather easy (relative to other languages, like C, C++). Having the goal to make VFP like another language could IMHO take away the strengts VFP has.

>In the same direction, do you suggest that VB stay like it is and doesn't include inheritence to keep it simple?

I doubt, but as far as I know, MS does. But for example i don't want to include strict typing because VB, C, C++ has it.

>>If we really want to do something that cannot be accomplished within VFP, it's better to use another language rahter than expand VFP to make this possible *IF* this something is some exceptional requirement that is only used in a very few limited cases.

>You would let VFP down to write a database application in another langage that doesn't do well with database because this other langage as a feature that doesn't exist in VFP?

If for example you want to write speach recognition into VFP, I'll say : let's do that with C, C++ or another language. If you want to store the spoken text you can write the DB part in VFP and let VFP communicate (DLL, COM, DCOM, ...) with this external program. Don't demand for native speach reqognition !

>>Hereby I think of the Assign and Access methods added in VFP 6.

>I do not agree with your appreciation (or lack of) of the Assign and Access methods. I find these methods very useful has it enable me to encapsulate property validation inside my class and doesn't require me to make 2 methods public to access a property, as in VB.

I'm aware this remark rocks the boat, but I cannot see any case where I definitely want these methods. Sure, it can be easier than having propertie validation within ordinary methods, but I don't think the Assign and Access methods should be a part of the OO philosophy. And if it should, it should be implemented corectly. For example, I wrote a, assign method for the rowheight property of a grid. It DOESN'T fire when you interactively change the rowheigt.

>>I'm sure there are also other examples to find which indeed are not as neccesary than things we really need (Better menu implementation (with pictures), maybe OOP menus, Dockable IDE forms, Resizable toolbars etc, all classes maintainable within the classes tab in the project manager, recycle deleted record, revise of the RELEASE command and method, FIX of the SQL filtered resultset behaviour, etc.).

>The priorities varies from one developer to another.
>- Yes I would like a better menu implementation.
>- I think that dockable IDE forms will be included in VFP 7.
>- Resizable toolbars? We can allready resize them.

I want the toolbar to behave exactly like the dockable debugger windows. Maybe this can be accomplished with dockable IDE forms. I don't know.

>- All classes maintainable with the class tab in the project manager. I don't understand that one. Can't you use the Class browser?

Some classes cannot be stored visually within the class tab: Headers, Pages, etc.

>- Recycle deleted records. I want that one too.
>- What about the Release?

See the post of Jim nelson to Graig in this thread.

>- Fix SQL filtered resultset. If it would mean slower query time, I'm against it. You allready have the NOFILTER option.

It would suprise me that it would mean more query-time for the exact same resultset.

>IMHO, Crystal Reports is better than VFP report writer in certain areas, but it still sucks.

Could you tell me where it sucks. If they're valid, I'll pass them to Seagate.

Walter,