Peter,

>Assuming that you know all about normalization (from the data angle), it seems that you don't apply it where it could. Let me give an example.

Whenever I do UI development, I go through quite a bit of effort to make sure the every form has a consistent interface. I think this is what you are calling normalization.

>From all what is going on at UT, I learned that most of the persons around, apply OO to the bones. You seem to do it too, hence all must be in methods, classes etc. But why ? who drew the rule on this ? Of course, from some technical point of view this looks right, but from the practical angle, no. That is, in not all cases. Well, what cases ? the cases that normalization tells it should be done otherwise.

It's not an absolute rule. It is a realization I think that you come to after doing several systems that reuse and change management are critical to long term success of applications and their life cycle. O-O is the current best software methodology to meet those goals.

>Now it is my hunch that you apply the OO rules to the bone, whereas I (and I think Walter too) apply normalization first. Normalization is my very first golden rule, and I won't step away from that ever.

I'm not sure why you think O-O and normalization are such different things. O-O can achieve a great degree of normalization. Have you read anything on Design Patterns yet? If not you should.

>Then you shouldn't have general statements like "a toolbar isn't legitimate in database-app environments" (similar).

I fully qualified that it was my opinion, and I gave you the particular rationale that I used to arrive at that decision. It's quite ok if you or anyone else has a different opinion on the topic, it doesn't bother me in the least.

>Of course it could be so that when *your* app is normaized, you (we) find that you don't have the general applicable buttons. But then I wonder what my database-app has superfluously opposed to yours. I mean, don't you have buttons for copy paste ?

yes the keyboard shortcuts are all there, the edit menu is available, I never had a client that wanted to sacrifice the screen realestate to get a few buttons that only use up about 20% of the total space a top docked toolbar consumes.

> don't you have a toolbar for functions that the user wants to perform from any place (compare "customize toolbar from Word etc.),

if my apps don't use toolbars, there is no need to allow customization of them.

>don't you have a help button ?,

I have a Help button as part of the button set on the form itself, I have a Help menu and the F1 key to launch help. All more efficient space users than a button on a toolbar.

>don't you have buttons for customizing forms and menu's ?.

Nope, the user and I design the UI right from the start there's no need for customization of a form or menu.

>So David, I am sure that you know about normalization too, and the only thing I expect (now) is that you don't apply this to all.

Well you are completely wrong in this assertion.

> and clicking a button would bring up the function besides Word. Still outside the main VFP-task that is.

An AlwaysOnBottom form can support an application wide rightclick context menu.

>This is really great, and without a toolbar you couldn't do this (okay, it's just "form" behaviour)

Yes it is a form behavior. Each form can support it's own rightclick context menu.