>Bob, I have just started trying to understand Codebook3. Would really appreciate if u could elaborate on the following line which was part of your reply to Ed. Are you suggesting that we should not use the business object ? And why ? Thanks
>
>>
>...... I think their business objects is a good idea that nobody should use.......


My first two codebook applications used business objects. They caused me nothing but grief during development. When the code wasn't quite right I had problems with instantiation. I NEVER had a business object that I could use twice in the same application, so what was the point? I found them hard to maintain and debug. It is simpler and easier to create forms without business objects. I had real problems with the original codebook only allowing ONE business object on a form. I had a form that required six of them (if keeping to the concept). I needed to create a new subclass that could handle mutiple business objects (linked list). All the methods that used the business object had to be modified to follow the linked list. Then the EBIZOBJ came out. If you have six business objects, you have 6 data loaders. That means 6 class definitions of different data environments. When you are on the form, how do you know what tables or views are open, and where?

In the end, I find it much simpler and just as effective to develop without business objects, or to use one big object.

I found them too complicated and unnecesary and without them the codebook is a better environment. I've also decided to forgo the 'object menu' idea. It works (although really slow) but I really really disliked having to allocate 1/2 hour of time every time I tried to add a new option to the menu. I am serious. That's how long it took, on average, when using the object menu builder. You know what? The old menu builder still works pretty well!