Ed...

You may be very sorry that you decided to dig this stuff up....

OK, lets go down memory lane:


Arnon asked you this in message 105961

Basically ,it is working the same way you would in FP2.x
by using variables (or in VFP you can use properties) to hold the values of
the current record etc.
IMHO VFP gives you several better options that gives you much more power
like private datasessions,buffering and views


Your reply in message 105965

Arnon, what power I lack using this approach? (surely i use buffered views).


Lets continue....


Evan Delay asked this in message 106004

Could you list the advantages and disadvantages of an unbound interface?

And Koziol asked this in message 106007

Hmmm....so...to borrow a bit from Arnon's post, it is very similar to the old memvars in GETs pairings in old FP?

I dunno about that. I find it much more productive to bind controls to views or tables. I originally tried something like that with VFP3 but it never worked well for me.

But, if it works for you...all power to you!!!

Do you think you could upload a sample form with small table to the Files section?

In fairness, here is you reply in message 106009 outlining the pros and cons:

Advantages:
1. Free navigation through data (no private DS, forget about triggering row buffer).
2. Full power in displaying control values/captions.
3. No necessity in resolving uncommited buffer changes when user closes form/app unexpectedly.
4. Seamless change from 'pessimistic' to 'optimistic' data sharing.
5. Full control when data is really saved.
6. Interface is not connected to data, so control classes can be moved from project to project with no changes.



Simply put, these ARE NOT ADVANTAGES. To be advantages, using the native features of VFP would have to cut you off from these items. In fact, many of these items do not make sense... Gee,it is really hard to resolve uncomitted buffers? In one of your previous responses, you said you use buffering. In a recent exchange with Jim Booth, I could have sworn you said you don't use buffering. Which is it Ed????

What the hell does seamless change from pessimistic to optimistic data sharing mean? You mean switching between pessimsitic and optimistic locking? Why the hell would you do that on a dynamic basis????? How is that we don't have full control when the data is saved...

Pathetic at best describes the argument you are attempting to make..

Lets continue...


Here is your attempt at a technical response to Koziol in 106013

In some sense, everything is similar. Just look at this as OO-version of standard xbase approach.
Instead of giving a code, I want to extend a little bit here to show your another similarity. When you use buffering, you have OLDVAL() and CURVAL(), right? Let say, when I start to edit a record I create record object (e.g. using NAME clause of Scatter command, if someone doesn't like scatter s/he can be sure that i create object differently), when it's going to Save.Click i create object from the same class and initiate it from record.fields again, i.e. I have 2 objects, one of them is equivavlent to OLDVAL() and another one is CURVAL(). Also, I can have the third similar object, which holds real user's entries. Is it not nice? Is it not powerful? Is it more like Fox2x, or truly OO-way?



Fox 2.x was more straightforward than what you are saying here... And, it sure is not OO......

The rest of the thread has much of the same stuff..... You have failed to truly step up to the plate and admit what is painfully obvious, you are trying to replicate what Fox gives you for free.

OK, some of the scatter to name, etc stuff is interesting. But it is not revolutionary. You lose it with all the activate and other code you have going on. It is terribly convoluded. Not a best practice at all

It looks like deja vu all over again...< s >