Forms Class Inheritance in Access 2007

  • Thread starter Thread starter CES
  • Start date Start date
C

CES

All,
I have been searching for the last couple of days on how Access implements inheritance, specifically with regard to forms. Unfortunately everything that I seem to find is related to .Net and not specifically to Access VBA.
My first question is does Access have anything equivalent to ASP.net Master Pages… by that I mean is there a way in which a secondary form can inherit all the objects, controls, properties and methods of a base form?
Secondly once you instantiate the class are all of the properties and methods of the base class available to the current form?
Finally, I found a 1999 MSDN article http://msdn2.microsoft.com/en-us/library/aa139986(office.10).aspx but I was hoping that someone might be able to point me to simpler examples of inheriting classes in Access, I would be grateful. Thanks in advance. - CES
 
is there a way in which a secondary form can inherit all the objects, controls, properties and methods of a base form?
Click to expand...

Maybe, but not to my knowledge and not that I've ever heard of.

John W. Vinson [MVP]
 
No, but if you create a main form, and then drop in an existing form as a
sub-form, then you are in fact making a new instance of that form, and NOT
copying it. All of your custom properties (pubic vars), and also any custom
methods (public functions) will work.

So, to "clone", or have a form with all of the save fields/data etc, you
simply drag and drop in the form in as a sub-form.

You can even drop in the sub-form as many times as you want. All of the
variables, code and everything is local for each sub-form...(each sub-form
represents a new class object based on the original form). In fact, that how
I created the following calendar in this screen shot:
http://www.kallal.ca/ridestutorialp/setdriver.htm
(each day is in fact a sub-form)

So, the closest approach is sub-forms. I talk about them here:

http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000005.html

However, we not talking about inheritance here, but only creating multiple
instances of the same form...
 
Not graphical inheritance, but it can be of some use, you can define a
'template' ( Tools | Options... | Forms/Reports | Form Template ) from
which NEW form will get the default look for new controls and so on.

Vanderghast, Access MVP
 
I'm not sure if this is what you are talking about doing, but a
"clone" of a form can be created by using

Set var = New Form_FormName

As long as that variable is in scope a replica can be made having all
the same properties, method, controls and such, but is in itself a
different form. You might do this in an ordering system where multiple
order forms could be open all containing data about different orders.
Once the variable is destroyed the instance is as well.

I usually do this in a class module so you can refere to the instance
of a form in different ways. Also I believe the form must contain some
code (even if it dosen't do anything) in order for this to work.
 
Not sure if instancing is what you are after, or be useful instead. A
form can be opened many times as a unique entity, but each would share
the same objects, controls, and code module.

Not exactly the same thing as the form would only exist once, but
usefull in say an order form - only one form need be made, but
multiple orders can be open at the same time.
 
Didn't mean to post twice, but the first didn't show up for two hours
so I wasn't sure that I actually did it or not.
 
storrboy said:
Didn't mean to post twice, but the first didn't show up for two hours
so I wasn't sure that I actually did it or not.
Click to expand...
storrboy ,
Thanks for your response... I was wondering if you knew of any resources were I might be able to see simple working examples? I went to Barnes & Noble yesterday and only found one Access book that remotely discussed Interface Inheritance and it was a grand total of two paragraph's.
One of the paragraphs however did state that while you can inherit methods a form each of those methods needed to be called on the new form. By that I mean if you had a base form called Form_Base, in order to call an event you would still need to refer to the event in the new form such as follows:

'Form_Base (the Base Form that encapsulates the events that you would like the new form to inherit)
Option Compare Database

Private Sub Form_Load()
MsgBox("hello World")
End Sub

-----------------------------------------------------------

'myForm (the form that inherits its methods from Form_Base)
Option Compare Database

Dim myForm As Form
Set myForm = New Form_Base

'When this form opens it would not automatically display a message box with the text of "Hello World"???


-----------------------------------------------------------
' in order for the message box to be displayed you would have to do something like this, once again I have no idea what I'm doing so the syntax is probably incorrect?
Option Compare Database

Dim myForm As Form
Set myForm = New Form_Base

Private Sub myForm.Form_Load()
' this should call the event on the base form but I'm not sure?
End Sub

In any event I really appreciate your help once again thank you. - CES
 
You can IMPLEMENT an INTERFACE.

To define an interface, get a new class where you will only define
'signatures' of the methods to be implemented.
To implement an interface, to a class (a form *is* a class with
graphical components), in the declarations section, add the line:


Implements ClassNameDefiningTheInterface



You will then HAVE TO define each method defined in the class-interface
inside this class.


Example: You decide to make a generic "wizard" that is made of a main form
with three buttons (back, next, finish) and a subform. You decide that each
form that will be displayed in the sub-form (each page of the wizard) will
have to 'implement' the methods: whosNext, whosPrecedant, ItIsDone, and
itDataAcceptable.


Make the new class name IWizard
-------------
Option Compare Database
Option Explicit

Public Property Get WhosNext() As IWizard

End Property
Public Property Get WhosPrecedant() As IWizard

End Property
Public Function IsDataAcceptable() As Boolean

End Function
Public Sub ItIsDone()

End Sub
-------------


Note that WhosNext and WhosPrecedant returns an object IWizard.

Save the class. Note there is not "working" code.

Now, in a typical form to be used as subform (page of the wizard), add the
line


---------------
Option Compare Database
Option Explicit

Implements IWizard
---------------


At that point, the first combo box (just the line below the title bar of the
'code' window ) you now have the options:

(General)
Detail
Form
IWizard



Choose IWizard


and now, in the second combo box, at the right, you will get the four
methods you are OBLIGED to implement.


The "Main" form buttons can now refer to object of class IWizard (while the
real object class type will be its name as form) without any problem, and
with full pre-compiled support and validation. In fact, that is exactly as
Interfaces work in Dot Net, from that point.



Implements is not Inheritance since with Inheritance, you would also get
code (from the basic class, as long as the method is not virtual).

You still can use inheritance by delegation, though. As example, when you
ask a car to start, in fact, it is more likely then engine, owns by the car,
that will start.


pseudo code
-------------------------
class car
{
dim motor AS engine

public sub start()
{
Call motor.start()
}
}
-----------------------


It is then said that class car inherited the method start() from class
engine through encapsulation-delegation (it owns an object of class engine
to which it redirects the method starts() ).



BUT, there is not real direct inheritance, visual or not, in VBA.





Vanderghast, Access MVP
 
I'm not going to pretend I know anything about inheritance, but I can
describe instancing for you. Also, all of this is based on older versions of
Access. If 2007 does not allow doing this anymore, then sorry to waste your
time. I believe I read about this in Access 97 Bible, but I've not looked at
Access books for some time so I don't know a currently recommendable one.


To keep this a simple explanation, let's say you have an order form
(frmOrder) with a textbox for OrderID.
In a standard module dim a form array with 3 elements, and a counter
variable.

Public FormArray(2) As Form
Public FormCounter As Integer

Create a function that creates an instance of the form and assigns it to one
of the elements, then increments the counter, so that we're not creating a
million of them. Note: when creating an instance, it does not become visible
until you tell it to be.

Function OpenNewOrderForm() As Boolean
If FormCounter > 2 Then Exit Function
Set FormArray(FormCounter) = New Form_frmOrder
FormArray(FormCounter).Visible = True
FormCounter = FormCounter + 1
End Function

In the frmOrder load event, assign a unique value to the OrderID, say using
the date and time, or something random so that you can tell a new form was
opened. Create a form, macro or use the debug window to run this function. A
new 'copy' of the form will open. When it does, the OrderID textbox will
contain a different value each time. You should now have three copies of
that form on screen (maybe hidden behind each other), and each can go along
it's own business, with it's own data, but all the events and other code
within it are the same. There is no need to call events, or try to manage
the form usage from some other module. Just think of it as having many forms
while only designing one.

As I said this example is only a simple one. Usually when I implement this,
I create a class for the type of form, and a collection to house them. For
instance, create a class module for Orders (collection) and one for Order.
This way you can create an Order class, assign it an instance of the order
form, assign properties like Form (so you can access the form itself - make
visible, setfocus etc.), OrderNumber, and whatever else. You'd then append
the Order object to the Orders collection and be able to manage all open
order forms like you do with the Forms collection, or the Fields collection.
The form would remain open as long as the object that created it existed in
the collection. Any functions that need to act on any given copy need only
refer to the collection and object, or if called form the form, pass a
reference of the form.

There are perhaps some drawbacks.
1) Using the filter and where arguments of the OpenForm method can't be
employed as you are not opening them this way. You can however affect
changes to the forms recordsource, filters and other properties before you
make it visible.

2) I've never tried doing this with forms that contain subforms - so I have
no idea how they would behave. Subforms are essentially instances themselves
so I think it would not be an issue, but I don't know for sure.

3) I've also never tried doing this with reports, but I kinda think they
should work almost the same way.

4) Using any code that use the Form Name as an argument may likely fail as
the same form is open numerous times. You would probably need to ensure that
the form reference, or some other uniquely identifying property is being
used (like hwnd).

Or did I just ramble on and not help?
Let me know.
 
Back
Top