Hi Walter,

SNIP
>
>>2) Next, a desire to see a VFP-to-VFP (native and between workstations) capability for at least SQL commands and their result-sets and preferably for all VFP table-manipulating commands;
>
>Can you explain this a bit more clear. I'm afraid I don't catch it.
>
I will get to this at the bottom of the reply. . .

>>3) Continuation of improvements to the UI parts of VFP, including new/improved (UI) objects and the OOPification of MENU/REPORT-WRITER in addition to the work of positioning VFP as the premier mid-tier option for n-tier applications.
>
>This has alway been the biggest pain in VFP. Probably due to the fact that most VFP object are not native windows controls.
>
SNIP
>
>I definitely want that a release method release the object under any circumstances (I still doubt for the release command). All reffering variabeles should be set to .NULL. I have no problems with a SET command that would allow the method to behave as in previous versions (E.g. SET FORCERELEASE ON|OFF).
>
>The release command IMHO should only release the variable, not an attached object, but having the same behaviour as the Release method is not a big problem.
>
Well first let me point out that the RELEASE of an array releases the memory occupied by that array, not just the memvar name referenceability. I see the object reference as exactly the same thing. Now if only the variable is released then I have no way of knowing/referencing the object later to release it.
Secondly, the documentation (in its four meagre lines) specifies RELEASE, not the Release() method. And the concept of an object releasing itself has always been a bit strange to me - get rid of me as I run is like suicide to me. Just doesn't make sense in my little head.

On the VFP-to_VFP thing earlier. . .

I want to be able, in the native VFP language, to have a SQL statement processed by another workstation and have the result-set returned to the issuing (of the SQL statement) workstation as a normal and regular cursor( or perform any updates or deletes, depending on the SQL statement issued). A VFP-Server, if you will, talking with VFP clients. No ADO, no ODBC, no SQL-passthrough, no anything fancy. Sure, maybe some new SET command or two, and/or maybe some new clause(s) for USE command, but that's about it.
I even believe that regular VFP (xBase) table manipulation commands could operate the same way. For instance, workstation issues a COUNT FOR... and VFP "knows" that the table in question is accessed by the 'server' running elsewhere and runs actual command there, returning result to expected area.
At the very least I would like to see this for SQL. Then, at least, we would have a chance to create n-tier applications which continue to use the VFP engine. Presently, n-tier means that we lose our beloved (fast and simple) VFP engine. What's the point of using VFP at all if we cannot use it's best feature???

Hope this explains better,

Jim N


>Walter,
>
>
>Cheers