>>Ok, we are rapidly moving from class versus instance programming into OO design issues. In ture OO the form would not do the importing or exporting of data, there would be another behavior object that did that. The OO desing of the behavior objects would provide a commmon developer's interface so that the buttons and forms could be generic while the behavior object was changed. This design, actually a bridge pattern, makes it even possible for the form to change its personality while it is running. It just simply instantiates a different behavior object and suddenly the buttons do something different.
>
>>I am not trying to be argumentative here, I am just really enjoying the give and take and I hope this thread is valuable to oehter as a result of you and I exchanging ideas.
>>
>>One thing that is really important if new ideas are going to make things better, is to have a healthy scepticism about them. Playing deveils advocate, you are giving these ideas that needed scepticism.
>
>I'm enjoying it too - although feeling a little out of my depth on the theory.
>
>I can see the importance of the Bridge structure. In my export example to allow you to export to DBF, XLS or TXT files for example. BUT I'm still don't see how it could be applied to a button calling a form-specific method. Sure, you could design it, but it would be counter-productive in time spent.
>
>Barbara

Barbara,

Not necessarily. If the form method simply passes the message onto the behaviro objhect then you needn't make any changes to the form or its code to get different behaviors. Of course you are right that this approach requires design ahead of time and anticiapting the various scenarios that the system will encounter. That brings us to the issues relating to analysis and design and the use of use cases to describe required system behaviors.