Using LotusScript user defined class. Here’s the snippet:
Class SomeClass
m_strStatus As String
m_strLog As String
' Constructor
Sub New (strInitialStatus As String)
m_strStatus = strInitialStatus
End Sub
' Get / Set Property 'Status'
Property Get Status As String
Status = m_strStatus
End Property
Property Set Status As String
If Status <> Me.Status Then m_strLog = "Status changed"
m_strStatus = Status
End If
End Property
End Class
In the Property Set Status procedure, I need to call back into the object to get the CURRENT Status to see if it needs updating (in the real code I need to do other things), however, the inequality test always indicates that Status = Me.Status. It seems that the ‘Me’ keyword is ignored. Any comments? I realise that I could retrieve the Status as I do in the GET, but surely this should work? In the real application, getting the status is more complex than simply referring to a member variable.
the class has a member variable ‘m_strStatus’ declared as a string. The Get and Set Properties operate on this variable.
The problem is that in the ‘Set’ property, the not equal test is trying to compare the incoming ‘Status’ variable with the ‘Get’ property result (to get the current Status whatever it is) by using the ‘Me’ keyword to refer to the instance of class object. This SHOULD access the ‘Get’ property, but it doesn’t.
This is a fact of LotusScript properties … inside any settor, Me.propertyName is identical to propertyName, and references the value passed to the property. If you want do to this test you must use m_strStatus, Me.m_strStatus, or come up with some other way to reference the data using a gettor.
As David already pointed out, one cannot access the property getter from inside the setter. A possible – and obvious – workaround is to replace the setter by a Sub, similar as in the example below. That’s what I usually do.
Did I miss something in the documentation about not being able to access a Property getter from inside a Property setter? The ‘Me’ keyword should indicate unambiguously that the call is referring to the object instance.
I know how I can work around it, but I would still consider this to be a bug. Anyone agree?
Having said all that, thanks to all for your feedback. Back to the coding!
But I very strongly feel in the Grand Scheme Of Possible Fixes, this one is so low it may as well be in the La Brae Tar Pit. I ran across this near a decade ago and have never mentioned it before, despite being ever so slightly vocal on other issues. (owlish stare)