Peter,

>Yeah, I think that is standard attitude nowadays.;) But please, don't call that the most friendly solution.

It's an opinion, we differ on it.

>"Nothing is lost" ? I think all is lost. When data has been typed, and that date (sorted out at the field level) was changed, it has to be reloaded, right ? So the typing was for nothing. It didn't vanish as such, so that's not what I meant.

The controls all still have their values. The ControlSources that they are bound to still all have their values (that is of course unless you have code some place the is clearing the content. I don't see that has to be "reloaded".

>Further more, it is not just about the visible data on a form, but also about data that needs replacement further down the line. Think about the RI.

Any non visible data still comes from some place right? That place should still be there. I'm not sure how RI come into play in this context either.

>It comes to the attitude again I'm afraid. I hope you 'll agree that indeed all can be validated right after pressing OK, but, that this just as well could have been done at the control level. It saves typing again.

Why does anything need to be retyped? With either control level or form level validation?

>But I know, we all started to learn that it sure is not convenient to valid at the control level. Think of web-apps ... Or better, having your normal app into a web-app. That's my problem now ...

99% of the web apps I've seen all delay validation until the form is submitted. To do otherwise requires extensive client side scripting and that just doesn't happen because of client side browser dependencies...

>I meant (our situation) the OO being on top of all user functions like an OS. It's the highest level of being generic. For fun, look at your own code. Is it really 100 % detached from the biz functions ? if not, could you do it ?

I take a more pragmatic approach to O-O development. If I don't forsee reuse of a piece of code that a form is using I'm quite likely to just throw that code into a method of the form instead of going through the effort of creating a business class. If sometime in the future that turns out to have been a bad design choice I'll move the code to an class and use it from the form and the other entity that needs the functionality.

>The "just loops" won't do with regards to the communication with the biz functions. Remember, all it detached, and both environments have to communicate with eachother. For example, the Valid code isn't part of the OO classes (objects), but part of the biz functions as they should be. So, the leave of a control must communicate with the biz function concerned. At that time, the biz function is on control, which comes to preparing for error messages (if applicable) which have to be dealt with by the OO-part again. In between the user is in control. So he/she decides where to go to, and in the end what event will fire when. This is normal obviously, but at the back the biz functions are running, knowing nothing at all. So in there, it's 100 % objects again, ready for all that may come to them. Well, not "all", and that's what my "OS" is taking care of.

There are many ways to bind the UI to the biz objects. It's just a matter of how you want to do it. There can be a direct object reference association between the two, this can in fact be a bi-directional association. It can be an indirect association that can be ControlSource based. It's easy enough to iterate controls and bizobjects based on a TableName.FieldName to find the association at runtime.

>Because all is normal classes, obviously this behaviour can be changed by the change of the one line of code concerned. This is nothing unusual. What is unusual however, is the things I control. Think of it; when this is outside the biz functions, it can be only about showing and entering data, right ? Well, that's what I spend 5 years of my life on. And I am not the only one working overhere. So let's say that I spend 5 years on how the user should browse through a form. Rather ridiculous, right ? well, that's whay it's so hard to explain.

Clearly you and I have a difference in opinion about UIs and the interaction of business processes.

>Yeah ? well, I'd say that an app that draws it's control data directly from the tables, isn't as felxible as could be.

Table buffering allows total freedom to bind to a table.field directly. I totally abandoned the FP2.x style of scatter memvar forms with VFP3 and have never looked back.

>Example : I don't want Y/N to display as data, and at the same time I don't want Yes/No in the table field. Now what ? Added to this, the app is multi-lingual. Then what ? there has to be the other layer in between. This layer could be a table, but this is nonsense. So it's just variables fed with the current language, translated from the normal table data, just as that a "Y" is translated to "Yes" (or translated to a checkbox).

I bind boolean fields to checkboxes, you have complete freedom to translate the caption with no effect on the underlying data.

Other times I use a "logical" binding of a control. The control is setup on the form with its ControlSource assigned to the table.field. In the init it unbinds itself, by moving the ControlSource to a custom property. Then the Valid() and Refresh() methods take on the responsibility of converting the particular UI requirements to the underlying data values. For the most part this is totally independent of the business objects.

>So in the end you are sort of right, though I like your word "trying" a bit less ;)

"trying" was not meant to be derogatory at all, I meant it as "doing" not "making an attempt to do" perhaps that just doesn't translate well to your native language.

>It sure is David. Did you ever think on how the event model works internally ?

Yes, in the last 27 years I've done a fair amount of work on code that involves event handling.