Jim,


>>Hmmm... What about multiple variables pointing to the same form ? If a variable is released, should it also release all other variables or set them to .NULL.. How should I release only one variable of say about 3 referencing the same object, without releasing the object ??

>By the way, I don't see setting a variable to NULL as "releasing" that variable - only changing its content.

I think the best way is setting the *OTHER* refering variables to .NULL. since other properties (e.g. of forms) could refer to the released object. Therefore also an object which has a reference to another object should be released. I don't think this is neat.

>>I think this is a matter of taste. I'm very comfortable with the release method. From an OO standpoint it seems reasonable to use the release method.

>Yes, I agree. I only argue that RELEASE should do exactly the same thing (you said differently earlier).

I did ??? Well I've must have been drunk.. ;-) I'll review my post to see where I was uncarefull.

>>This standpoint definitely makes sence. < G > But this is whole new topic. In short: you want some Client-server capability which is wholy transparent trough the language. I think there is a lot to say about this, maybe this is worth a new thread.

>Maybe worth a new thread, but I feel that it would be wasted without there being a "Wish Discussion" category. To me this one, especially, would require lots of dialogue and ideas before a practical wish submission could be developed. To me a "Wish Discussion" category is the only reasonable place for this. The editable wish thing recently delivered on UT is too far out of the way and is not conducive to "dialogue".

Yep, I fully agree. Seems we are one of the few who believe this. On the other hand we are one of the few, who holds this kind of discussions; seems we are a minority. < G >.

>>>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.
>
>>I know this kind of thing is very difficult to implement and VFP being native Client/server would probaply mean a great deal rewrite of the product. But you're right this definitely would mean a great and big step forward.

>This is something genuinely UNKNOWN to you and me. For instance, we hear a lot about the old FP legacy code and its being a burden in VFP. Well, at one point FP was scheduled to have a C/S capability. Who can say that much of that code is not already inside the product??? Who can say if possibly some of that code has been used in delivering what we have today with views, etc???

You're right, we don't know, but I assume that accomlishing this is more complex
than at first sight.

>We don't lose de VFP engine, but need a little middleware to let the two tiers communicate. Presently, this piece of middleware has to be managed by the programmer. Your proposal is to let VFP handle the middleware hidden for the developer (and even a step further). This I like very much, because building good middleware is difficult and timeconsuming for most developers.

>It is not only difficult, but also subject to required detailed revision whenever a table format or field format might be changed.

I guess this would depend on the implementation of the middleware.

>>At the very least VFP should be able to pass cursors and views from one to another tier in a very transparent way, without XML, ADO, OLE DB etc..

>Yes, exactly, and what I also want is to do this implicitly by SQL (or xBase command) rather than explicitly.

hmmm. This new topic is so new, i've got to rethink this whole issue before I can take a definite standpoint. Sure I like the idea, but have no idea how this should be implemented (syntax and new features, not C++ implementation).



Walter,