On Mon, 03 Nov 2003 12:33:47 GMT, "rkc" <rk*@yabba.dabba.do.rochester.rr.bomb>
wrote:
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:06********************************@4ax.com.. . Here is some code to generate code for raising and getting information
about custom errors in an application. Executing the GenerateXyzErrDefs
procedure generates the code.
I am completely baffled by this.
Why generate a basXyzErrorDefinitions module that contains nothing but
duplicate functions?
Why not generate a class that not only raises and reports on the error, but
also initializes the pairs?
I'm not sure I understand the question, so I'n not sure if this addresses it,
but...
Instances of clsErrorDefinition represent individual error types. Each of the
functions in basXyzErrorDefinitions accesses an instance of clsErrorDefinition
for a particular type.
I don't want to generate separate class modules for each case because
A. That many class modules would be a big clutter in the VBE.
B. Calling code would have the extra code and extra overhead of creating an
instance of whichever class before using it.
C. It is nice for the calling code to be able to implement functions that
accept or return a value of type clsErrorDefinition, and use early binding
rather than having to use Object type because multiple class types are
possible, and resolve everything else at run-time. An Interface could solve
that, but wouldn't be compatible with Access 97 - which is nice to be.
If I don't generate separate class -modules- for each case, then something has
to initialize them and provide access to the correct one by name. I could
have passed just the ID, and let the class look up the rest from the table,
but the generator is already reading the table, and the resulting code is nto
to be directly maintained anyway, so why not just dump all the info into the
code during code generation?
We're not worried about duplication in the generated code because it's not
manually maintained. The function pattern need only be maintained in one
place in the code generator, and the error details need be maintained in only
one place, the table. I guess it's kind of like doing a mail merge in MS
Word. I probably should have a comment automatically inserted at the top of
the basXyzErrorDefinitions module saying how to maintain and regenerate it, so
it's obvious to anyone maintaining the code.
Note - in my original code, the following line should be removed because it
was part of an experiment that failed, and nothing now uses it...
Private Const mycVBErrMethodNotApplicableInContxt = 444&