<I><FONT COLOR="#663300"> If you <i>do</i> have a different class you wish to use, simply leave the <b>cDataEnvironment</b> property of the DELoader blank, and then modify your bizobj's Init() to instantiate your custom class.</FONT></I>
That is essentially what I did, but it is not effecient because I have a default cDataEnvironment for the bizobj class and that gets loaded by default and then I call LoadDataEnvironment again to load the one I want for the particular runtime instance of the bizobj. What I am after is an option to provide a cDataEnvironment at runtime prior to the Init of DELoader. I have a generic Party bizobj that I use over several data environments.
<i><font color="#663300">Heck, if I could guarantee that no one is using GUI bizobjs anymore, I'd change the base class of the bizobj to something a lot more lightweight!! </font></i>
That to me is part of the great debate for any additional forward movement of Codebook. We now have 6.1 in place and can say that Codebook 6.1 is there for folks who want to put GUI controls on their business objects. But I am under the impression that there is general agreement that GUI controls should be separate from business logic. I know how much I have benefited from forcing their separation, even though FoxPro makes it so easy to combine them. <g> It seems reasonable to me that efforts at version 7 should be based on correcting past mistakes, streamlining the framework, and necessarily sacrificing backward compatibility as a by-product.
At this point I have made such significant modifications to some basic codebook objects, that I probably couldn't risk overwriting the base library. Some things, like unprotecting properties, can only be done at the c-level.
Pamela
pamela (AT) eagle-crest .DOT com
©2001 Pamela Thalacker |
