why cant i see the message box on screen?

[Paul_Hossler]

Basically yes, but the point is that no function code goes in the Interface class, so whilst you declare the variable as implementing that interface, you actually create a variable using the implementing class.

Yes and Yes

You seem to know this stuff

Paul

[Aflatoon]

I've read PED a few times.

[Paul_Hossler]

I've read PED a few times.

Shows you how far back I am - I don't even know what a PED is

Paul

[GTO]

Shows you how far back I am - I don't even know what a PED is

Paul

Me neither! Nor do I know what "...EF imploding..." means.

Pretty please?

Basically yes, but the point is that no function code goes in the Interface class, so whilst you declare the variable as implementing that interface, you actually create a variable using the implementing class.

Hi xena2305,

I hope you will not mind me glomming on to the conversation?

@Aflatoon:

Howdy

I have only read the help topic a couple of times and could not make it work. Did find a coupleof short examples tonight, and followed well enough to make something that didn't set the PC afire.

As to "...no function code goes in the Interface...you actually create a variable using the implementing class..."

Is this on the right track?

Class named: impEmployee

[VBA]Option Explicit

Property Let EmpName(AString As String)
End Property
Property Get EmpName() As String
End Property
Property Let EmpDateOfHire(ADate As Date)
End Property
Property Get EmpDateOfHire() As Date
End Property
Property Let EmpAppraisalDue(ADate As Date)
End Property
Property Get EmpAppraisalDue() As Date
End Property
[/VBA]

Class named: impInsurance

[VBA]Option Explicit
Property Let Rate(ARate As Currency)
End Property
Property Get Rate() As Currency
End Property
Property Let InsCompanyName(AInsCompany As String)
End Property
Property Get InsCompanyName() As String
End Property[/VBA]

Class named: clsEmpData

[VBA]Option Explicit
Implements impEmployee
Implements impInsurance
Private EmpAppraisalDate As Date
Private EmpDOH As Date
Private EmpName As String

Private CompanyName As String
Private Rate As Currency

Private Property Let impEmployee_EmpAppraisalDue(RHS As Date)
EmpAppraisalDate = RHS
End Property
Private Property Get impEmployee_EmpAppraisalDue() As Date
impEmployee_EmpAppraisalDue = EmpAppraisalDate
End Property
Private Property Let impEmployee_EmpDateOfHire(RHS As Date)
EmpDOH = RHS
End Property
Private Property Get impEmployee_EmpDateOfHire() As Date
impEmployee_EmpDateOfHire = EmpDOH
End Property
Private Property Let impEmployee_EmpName(RHS As String)
EmpName = RHS
End Property
Private Property Get impEmployee_EmpName() As String
impEmployee_EmpName = EmpName
End Property

Private Property Let impInsurance_InsCompanyName(RHS As String)
CompanyName = RHS
End Property
Private Property Get impInsurance_InsCompanyName() As String
impInsurance_InsCompanyName = CompanyName
End Property
Private Property Let impInsurance_Rate(RHS As Currency)
Rate = RHS
End Property
Private Property Get impInsurance_Rate() As Currency
impInsurance_Rate = Rate
End Property
[/VBA]

In a Standard Module:

[VBA]Option Explicit

Sub example()
Dim cEmpDate As clsEmpData
Dim iEmp As impEmployee
Dim iIns As impInsurance


Set cEmpDate = New clsEmpData
Set iEmp = cEmpDate
Set iIns = cEmpDate

With iEmp
.EmpName = "Mark"
.EmpDateOfHire = #6/1/1988#
.EmpAppraisalDue = #5/10/2012#
End With

With iIns
.InsCompanyName = "BC&BS"
.Rate = 167.42
End With

MsgBox "Dang! " & iEmp.EmpName & " has been here for " & Format(Now() - iEmp.EmpDateOfHire, "yy") & " years! I know he carries " & iIns.InsCompanyName & "; their good but the rates are high. " & vbCrLf & _
"Mark pays " & iIns.Rate & " per paycheck, just for himself. I sure hope I remember to write his appraisal," & vbCrLf & _
"it is due on " & iEmp.EmpAppraisalDue, vbOKOnly Or vbInformation, vbNullString
End Sub[/VBA]

Thank you so much,

Mark

PS. Hi Paul!

[shrivallabha]

Maybe ---> PED

[Aflatoon]

@all - yes PED = Professional Excel Development (Edition 2 now).

@GTO,

Where did 'EF implodes' come from? (EF = Excel Forum, by the way)

Your code example is functionally correct, but not really how I would use it. I think of it as being more use when several classes share some basic characteristics. For example, you might have classes that represent different types of Employee: Salesman, Office worker, warehouseman, manager and so on. Each class will have its own specific implementation - properties and methods unique to it, but they are all also employees and therefore share a lot of common properties and methods, so you might create an Employee interface for use here (with properties like Name, address, DOB, hire date, salary and so on). By implementing the interface in all the other classes, you can process them all as employees, regardless of the actual class involved. So if for example your code needed to loop through all employees and apply a flat 3% pay rise, you could do that with one variable, rather than having to have a variable for each class and checking at runtime which type of object you are dealing with.

Incidentally, this is the difference between the TypeName function and the TypeOf operator: the former returns the name of the class, whereas the latter tests whether an object implements a specific interface (That is why, when looping through controls on a form, a test to see if TypeOf matches MSForms.Checkbox will also match option buttons and toggle buttons - they implement the CheckBox interface - but using TypeName(ctl) = "CheckBox" will only match CheckBox objects. But I digress. )

Does that make sense?

[Paul_Hossler]

Hi Mark -- the more the merrier

As an experiment I created an 'EmployeeData' interface class, and also 'Employee' and 'Subcontractor' classes that Implements 'EmployeeData'

My 'Company' is a simple array of 'EmployeeData' and then I can assign either 'Employee' or 'Subcontractor' variables to it.

When I use a 'Company' entry, I get the method or property from the correct class.

Any you're right ... the Help leaves something to be desired

Aflatoon is better

Paul

[Paul_Hossler]

[quote=Aflatoon so you might create an Employee interface for use here (with properties like Name, address, DOB, hire date, salary and so on).[/quote]

In the interface class I have Public variables that all implementing classes will want to use.

In the implementing class, it seems I have to have Private versions of those also. Somehow that just doesn't feel right, so I have to be refering to the interface variables wrong.

Got a simple example?

Thanks

Paul

[Aflatoon]

Can I ask why you have public variables in the interface (or in any class really)? Much better, in my opinion, to do it the way Mark has it and use public property routines and keep the variables private.

[Paul_Hossler]

Of course you can ask

The online help example ...

Example
The following example shows how to use the Implements statement to make a set of declarations available to multiple classes. By sharing the declarations through the Implements statement, neither class has to make any declarations itself.
Assume there are two forms. The Selector form has two buttons, Customer Data and Supplier Data. To enter name and address information for a customer or a supplier, the user clicks the Customer button or the Supplier button on the Selector form, and then enters the name and address using the Data Entry form. The Data Entry form has two text fields, Name and Address.
The following code for the shared declarations is in a class called PersonalData:
Public Name As StringPublic Address As String

.... talks about sharing variable declarations in an interface clase

Now ... if all the implementing classes will need Name and Address, it would sort of make sense to put them in with the other common declarations, etc. in the interface

When I do that, there seems to be no way in the implementing class to use them, unless I'm missing something

Paul

[Aflatoon]

Oh, I see. I haven't read the online help (Mac online help ain't the same, I suspect) article, but I suspect it is basically just saving you the trouble of putting property procedures in the interface class. You add a public variable in the interface (which gives you a read/write member), but then in the implementing class, you actually use property procedures and private variables as you would (ought) in any normal class. So for example (air code warning), in your EmployeeData interface you have:
[vba]Public Salary as Double[/vba]

but in the implementing class you would use the typical:
[vba]
Implements EmployeeData
Private mdblSalary as Double

Public Property Let EmployeeData_Salary(Value as Double)
mdblSalary = Value
End Property
Public Property Get EmployeeData_Salary() As Double
EmployeeData_Salary = mdblSalary
End Property[/vba]

[Paul_Hossler]

Ahh - that would have to be it. I'd expect there's no reason that the private variable couldn't be the same name, as the interface class one, and then you wouldn't even have to edit it

[vba]

Implements EmployeeData

Private Salary As Double

Public Property Let EmployeeData_Salary(Value As Double)
Salary = Value
End Property

etc.

[/vba]

Thanks

This has been a very educatiional topic

Paul

[Aflatoon]

Thank you too - it has been useful to refresh my memory of this stuff!

[GTO]

@Aflatoon:

Hi there, sorry for the slow response...

@all - yes PED = Professional Excel Development (Edition 2 now).

@GTO,

Where did 'EF implodes' come from? (EF = Excel Forum, by the way)

I no doubt botched that a bit from memory. I cannot seem to find my way back to the thread/poll, but I think it was a comment you made - maybe closer to '...EF imploding...'

I did stop by there tonight, just jumping around a bit. I think I get the drift...

Your code example is functionally correct, but not really how I would use it. I think of it as being more use when several classes share some basic characteristics. For example, you might have classes that represent different types of Employee: Salesman, Office worker, warehouseman, manager and so on. Each class will have its own specific implementation - properties and methods unique to it, but they are all also employees and therefore share a lot of common properties and methods, so you might create an Employee interface for use here (with properties like Name, address, DOB, hire date, salary and so on). By implementing the interface in all the other classes, you can process them all as employees, regardless of the actual class involved. So if for example your code needed to loop through all employees and apply a flat 3% pay rise, you could do that with one variable, rather than having to have a variable for each class and checking at runtime which type of object you are dealing with.

Thank you for taking the time to answer that. As to my delay in response, I was hoping to have the time to try that, on a tiny scale of course, just to see if I am still following (which scarely, I sort of think I am)

Incidentally, this is the difference between the TypeName function and the TypeOf operator: the former returns the name of the class, whereas the latter tests whether an object implements a specific interface (That is why, when looping through controls on a form, a test to see if TypeOf matches MSForms.Checkbox will also match option buttons and toggle buttons - they implement the CheckBox interface - but using TypeName(ctl) = "CheckBox" will only match CheckBox objects. But I digress. )

Does that make sense?

Incidently? I am chuckling, as whether you happened to have spotted a recent answer I gave, or by happenstance that you gave that example, I am suddenly aware that my answer was less stellar than I believed

I was also hoping to test that, unfortunately, not such a relaxed day though (and/or just muddled brains day for me).

Thanks again - hopefully I get a respite someplace in the morrow (and a chance to try some more),

Mark

[Aflatoon]

Hi Mark,

I no doubt botched that a bit from memory. I cannot seem to find my way back to the thread/poll, but I think it was a comment you made - maybe closer to '...EF imploding...'

I did say that, but not here (it was here)

Incidently? I am chuckling, as whether you happened to have spotted a recent answer I gave, or by happenstance that you gave that example, I am suddenly aware that my answer was less stellar than I believed

Pure serendipity, actually.