jwcolby
jwcolby at colbyconsulting.com
Tue Aug 7 15:19:09 CDT 2012
And I do the same. In my classes (which also have no constructor) I build an mInit() method which I call on the line after I instantiate the class, passing in any and all variables required for that class. There is in fact a Class_Initialize, though it cannot be passed parameters. I often use it however to initialize collections and stuff like that. Anything that needs to be ready when my mInit() is called. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 8/7/2012 3:51 PM, Kenneth Ismert wrote: > Incidentally, this whole initialization brouhaha is all due to some > "Incidental Complexity" built into VB6/VBA: the lack of proper object > constructors. > > In every modern language, you can specify a custom constructor for each > class. In VBA parlance, this would look like: > > ' SomeClass constructor > Private Sub Class_Initialize(sParm1 As String, lParm2 As Long, vParm3 As > Variant) > ... > End Sub > > Creating this class would look like: > > Set rClass = New SomeClass("parm1", 2, Null) > > Since Access forms are classes, this would let you do things like: > > Set rForm = New Form_Orders(vCustID:="a123") > > But instead, Microsoft punted, and we got Form.OpenArgs, a poor substitute. > Then, Access allowed multi-instance forms, but at the expense of not > specifying any OpenArgs at all. Poop! > > So now, due to outdated language design, and lack of good substitutes, we > are wallowing in productivity-robbing alternatives, all due to incidental > complexity. > > My approach is simply to simulate a proper class constructor, which passes > typed variables to a class instance. > > -Ken >