how to inherit form instance in new object

dear all,

previously Christian (Bitsqueezer) was helping me out with another question and then he mentioned about forms having public properties as a proper interface to go about things. that sparked off this thought of inheriting a particular form instance. here's what i wrote to him in that question but later decided to post it in a new question as i think the topics are different!
======================
whao Christian! i didn't know we can use properties in the code behind class for forms! but like what you said before, forms and reports are special classes. hrmm. with that i can actually use Implements in a form's code behind class to specify that it must expose certain properties. hrmm. hrmm..

what do you think Christian, is it an extremely bad idea?

if i do something like

Dim frmChild As Class1
Set frmChild = Form_Form1

and i Form_Form1 implements Class1, immediately i lose all the other properties of the form.

so we're going into OOP (ok i know heaps of experts has castigated me on this haha - but hey, i'm just a developing programmer learning!! = ))    ), and i need Form_Form1 to inherit from Form (which it is right now), and i also need it to implement the interface for Class1.

so Christian if i

Dim frmChild as Class1

and also put a variable pointing to Form_Form1 inside frmChild, then frmChild will implement Class1 AND also "inherit" Form_Form1 (through using the Implements keyword) right?

but 2 problems here.

1)  i would have to manually implement every single sub and function of Form
2) the Interface class should NOT contain any code - which is why my programme kept on crashing previously and you taught me not to put any code in the interface class.

what is the right way to go about doing it?

thanks Christian!! = ))

P.S. i know i'll having to put in some mechanism to choose the form instance but that can be easily solved so am not focusing on that but rather the bigger and deeper issues of inheritance of a form instance and also about inheritance in VBA in general.

i've read a few articles but they all point to Implementing a class with code in it already - the big no no that caused all the headache for me previously

here's a link to a discussion with David Fenton and Steve Jorgensen on the topic too http://bytes.com/topic/access/answers/195390-faking-inheritance-vba-remove-code-duplication
developingprogrammerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

BitsqueezerCommented:
Hi,

Inheritance: This is only possible in real OOP languages, VBA doesn't support that. The only kind of "inheritance" possible is a) to insert the parent object simply as public property into the child class or b) insert the parent object as private property into the child class and create wrapper procedures for all the wanted properties and methods of the parent object, so you are able to overwrite them with own code.

Form class modules: Be careful, a form CAN HAVE a "code behind" class module and if it has one it can be mostly handled like a simply VBA class. But it IS no VBA class, so you can do some things with it which you can't do with VBA classes (like using the basic Form or Control classes of Access or using objects like in the control collection as properties of the form) and I think you can't do anything with it which is possible in VBA classes (but have no example at the moment).

So this means, you can of course add your own public properties to it and you can of course also use the Implements keyword to implement any Interface class into it and handle it with an Interface object variable (best example: You implement an Interface class to any form which uses an "AdvancedRequery" method, so you can call that externally without knowing how the form is performing it as one form uses the Me.Requery, another sets a new RecordSource, a third uses a standard filter or positions the cursor back to where it was, whatever).

To handle it, you would do this:
Dim objForm As Form_Form1
Dim objIForm As IForm

Set objForm = New Form_Form1
set objIForm = objForm

objIForm.AdvancedRequery

Open in new window


So you see that you can't simply set the interface object to the class module name, "Set objIForm = Form_Form1" is not possible.

In this sample one would say "what's that good for, does need a lot of extra code?". It begins to make sense if you have added 20 completely different forms to a collection:
Dim objIForm As IForm
For Each objIForm in colMyTotallyDifferentFormObjects
    objIForm.AdvancedRequery
Next

Open in new window

That's the standard way an Interface class is used because as the name says: You want to have a standard Interface for each completely different object where you don't know the object type and don't want it to know. Think of the headphone plug Interface: The headphone doesn't want to know what's behind the plug, it only wants to use the plug Interface, independent of if this is part of a MP3 player, a CD player, a video recorder, a game console, whatever.

Interfaces with no code: To say it with your words: "Hrmmm"...:-)
I said that an interface class should not contain any code, only the naked procedure/property list. That's the standard way of doing it, but an advanced method which I didn't mention to not confuse you is that an Interface class can of course contain code.
For example, you can use a class module as Interface class but you can of course also handle it as a normal class. It's only the "Implements" keyword which makes the difference and which makes a class module an Interface class in the other class which uses it. So it is a possible method to create code inside the properties and methods of an Interface class which can then be used to handle standard implementation code. In the example above, you would create a sub in the Interface "IForm" like this:
Public Sub AdvancedRequery()
End Sub

Open in new window

But why not:
Public Sub AdvancedRequery(Optional frm As Access.Form)
    frm.Requery
End Sub

Open in new window

Now you can implement that in the Form:
Dim objIForm As IForm
...
Private Sub IForm_AdvancedRequery(Optional frm As Access.Form)
    objIForm.AdvancedRequery Me
End Sub

Open in new window

(it's of course silly in this example as you would normally simply write "Me.Requery" into this sub, but it should show the method only.)
As you see, you can now handle standard ways of implementing an Interface with one and the same class, that makes it very easy to fill standard implementations by copying it from one class module to another so you have always a standard implementation which executes code and you only need to change the implementation where it should execute something else (or simply add something to the standard implementation by not removing this line).

Now you have something new to think about, I can see your brain is smoking again and you are switching on your internal ventilator over the weekend to blow it away...;-)

TCSOA gave you a new chapter in developing...;-p

Cheers,

Christian
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
developingprogrammerAuthor Commented:
hahaha yup yup Christian my brain is definitely smoking!! but in a good way cause you're giving me so much of your time just to train me up!! thanks Christian and i'm a very very proud student of TCSOA!! = ))

(re-reading this and all your other posts many, many times hahaha = ))  )
0
developingprogrammerAuthor Commented:
phew Christian i read through all your posts in all my questions now and whao they're great!! = )) i can really understand how you are linking each dot step by step such that everything is very well connected and well expressed = ) definitely makes 100% sense!! = ))
0
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

BitsqueezerCommented:
;-)
0
developingprogrammerAuthor Commented:
hi Christian, i'm thinking of using a dictionary object for DoCmd.OpenForms argument. i can only pass strings however there is a method that allows me to pass the object's pointer. what do you think of it - would you recommend me against using it cause it's risky? here' the question if you don't mind taking a look! thanks Christian!! = ))

http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_28228242.html#a39456756
0
developingprogrammerAuthor Commented:
Christian thanks for the fantastic sharing on the implements - as always fantastic = ))

right now i'm only using the interface for one object. kinda defeats the purpose at the moment, but remember you mentioned that i'm having many stacked procedures and refactored functions unnecessarily? i went to think about it cause i had a purpose but i couldn't express it well - but now i can ha = ) and the thing that was always in my mind was scalability. just like using SQL instead of looping through recordset, if i use SQL, even if the records grew from 20 to 100,000, it would still be just as fast more or less. i can quote the results a super expert from EE who did testing on a local machine and also on a 100 MBit network where he was the only user then = PP

of course SQL and code are different. but i wanted to train up myself for very scalable things = )

and that's why i'm using an interface for all my classes now even though i only have a 1:1 relationship for each interface.

but what you've introduced to me will help me when i'm actually scaling up - which is super duper important, and that's why your comments are always of utmost significance to me! = ))

Christian i posted a question on "do yall use .mda files?" and that's very related to scaling. code distribution. just like what you just taught me about standard code in interfaces - scalability.

hrmm it's slightly crowded in that question and i don't really want to draw you into a battleground haha cause i know your time is precious, but i think without saying much you already know how i think and how i feel, so without risking typing too much, i came to the conclusion in my mind that i would like to ask you to share your thoughts on how you distribute your code! = ))

so Christian! may i politely ask if you could take a little time to share how you distribute your code to your users? i get the sense that you're using Access as FE and SQL Server as BE for your global ERP system = ) that would be the ultimate test cause there is no way you can fly to all the countries and fix it all in person, so code distribute for you must be a masterstroke or else the master will stroke! with a cane! haha = )

here's the link Christian! am really really looking forward to hearing your thoughts on it - as always!! = )))

http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_28233717.html
0
developingprogrammerAuthor Commented:
hi Christian!

ok i just re-read your post 3 times again and yup i've finally got it.

2 things. first you mentioned about adding functionality to forms.
===========================================
hrmm yup definitely good but when we use

Dim objForm As Form_Form1
Dim objIForm As IForm

Set objForm = New Form_Form1
set objIForm = objForm

objIForm.AdvancedRequery

Open in new window


, that limits the use of objIForm to whatever procedures IForm has inside it.

so we've got 2 objects,

first is objForm which and use all the normal things a form can use EXCEPT for the interface procedures because they are private

second is objIForm which can only use all the procedures declared in the interface class.

is this correct Christian? i'm quite sure it is. so objForm --> for all normal stuff, objIForm --> for all extension stuff. very neat and tidy. but we can't get an objULTIMATEForm where we can do both the normal and extension stuff right?

===========================================
the second thing you mentioned is the easy roll out of generic code in the interface class.

we do this by putting the code inside the interface class and then when we're implementing the interface in a specific object, the 1 liner additional code to make all this work is..... ta da! a line of code to call the same procedure in the interface class --> when we say same procedure we mean the procedure we're implementing in the specific class, but just without the prefix of the interface class' name.

ok am just paraphrasing but it really helps in me understand what you're sharing = )

yup Christian this generic code in interface class helps A LOT! i was figuring out a solution for this previously and ended up creating ANOTHER interface for generic code - how silly huh! haha = ) but now that i know this generic code technique in the interface class, it definitely helps so much more!! = ))
0
developingprogrammerAuthor Commented:
Ok got it sorry Jim!!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.