David,

Following the discussion between you and Walter (see below copy too), I get the hunch that, in fact, we might differ in our opinions on applying normalization. Could that be right ?

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.

When I can choose between buttons on the form and buttons on the toolbar (and I can), de buttons allpying to the whole app at all times will be in the toolbar, and the buttons that apply to the form will be on the form.

Now, from the normalization angle, I don't think anyone, nor you will disagree with this. Right ? However ...
Where I just apply this (for me) strict rule, you seem to have other reasons not doing it. And the toolbar is just an example (!).

Another, but related, thing :
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.

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.

As a small side-story I could tell that is wasn't for nothing that (as I told earlier) have the self containing objects from the beginning (1987). As you know, this was sure not because of FoxBase could do it. It was because normalization told that it should be done like that. And o yes, back then OO already existed as a phenomenon, but I don't think the tools existed already. And if they did, I didn't look into it for sure.
This small story is only here because I'd like to "prove" that on one side I state that OO is just the right thing, but on the other side (may) situations exist where it just should not be applied. Let me be clear : technically it always could, but in cases it is not "practical" it turns out that stuff isn't normalized properly.
And here we are back to the UDF's, or the ON ERROR if you like.

I guess (now) that the whole interesting discussion comes to you proving that the nornalization I talk about, *can* be applied within pure OO only. And you are entitled to of course. But :
Then you shouldn't have general statements like "a toolbar isn't legitimate in database-app environments" (similar).

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 ? don't you have a toolbar for functions that the user wants to perform from any place (compare "customize toolbar from Word etc.), don't you have a help button ?, don't you have buttons for customizing forms and menu's ?. Obviously these are my buttons, but it's only the beginning and (I think) rather general to each app in the world. Dedicated apps (e.g. ERP, accounting) have some more ...).

I agree with you that the mouse is farther away from the form. 100 % right you are. However, anyone specifically wanting to use the mouse, isn't in a hurry at all, so he/she can just as well take this extra time. IOW, all functions should be addressed to by keys just as well (just my opinion here).

Lastly, I, again, want to refer to larger apps like ERP, and all in there not being so normal at all. If I had to had all buttons available on the form, really, it would often come to, say, three controls on the form, and 30 buttons. You know how I call this ? not normalized ... That is, when 25 of those buttons apply to general functions.

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.
I just do, and that looks to be our difference on "opinions". And why not.

PS: Before you say it : I don't think it is 100 % legitimate to say that instead of toolbars there is a drop down menu instead (see your very last line below). I am not sure whether you would agree upon having the menu in a toolbar. Anyway, one of my toolbars just contain menu-items (opposed to buttons), and I think it is legitimate to have them in a toolbar instead of in a fixed position. I am not in favor of let a toolbar float around the screen (like you are not), but I am in favor of chosing where it's docked. Besides that, I wonder if anyone ever saw the huge possibilities in moving the toolbar outside of the VFP-app. In our case, the VFP app would be minimized, the toolbar still around (besides Word or so), and clicking a button would bring up the function besides Word. Still outside the main VFP-task that is.
This is really great, and without a toolbar you couldn't do this (okay, it's just "form" behaviour)

Peter



>Personally I find toolbars pretty much a waste in a database app. Docked they take up more screen real estate than equivalent controls in a container right on each form. Docked they require more mouse motion to get to them. Undocked they are always getting on top of something and they need to be moved around. So on the whole I don't use toolbars inside my apps. I think they are good for things like VFP itself, Word, Excel etc, but not in a form centric database app IMHO.

>
>>OK, that is you vision. Personally I like to develop database apps like they were just applications like outlook or excell. Just see the application as a document holder. Therefore toolbars are neccesary. For example: if my reports (Crystal Reports) were generated they show in a new window like a document: You can search through the document, Adjust the view (zoom), have a document view (the group tree), can archive, print, export and mail it.
>
>But those are basically menu replacement type toolbars. Toolbars are one click items that do the work of several menu or dialog box selections.
>