VBA class modules & factory design (2 Viewers)

[Albert D. Kallal]

I would argue that if you are lazy (and have MZTools) then creating accessors (let, get, set) for all class variables save a lot of coding time. With MZTools it takes a second to create the accessors from a class variable, but now coding is much faster especially with larger classes. I do not have to remember variable names, scroll up to the top to see what I called a variable, or type a variable. I simply type "Me." and intellisense takes over. Further there is a good chance that the accessor needs more code then simply setting or returning the value. There may be some checks in the accessor. So I might as well start with the stub to begin with.

However, for some reason there is a shortfall in vba that defeats good use of accessors. Maybe someone knows why that is. Unlike in .Net private accessors cannot be called inside the class as would be expected
If you type "Me." they do not show in intellisense
nor can you call them by Me.somePrivateProperty
This kind of defeats the whole purpose. You have to call it without Me.

The other thing that is annoying is In VBA, you cannot have a property with a private Let and a public Get directly. VBA's property accessors (Property Get, Property Let, and Property Set) must all be declared with the same visibility level—either all Public, all Private, or all Friend.

But any var declared as public in that class? You get intel-sense anyway - hard to make a case for then writing out a getter/setter, right?

There are SOME use cases for Get/Set, but 99% of the time, if you just setting a var value? Make it public - you don't need the get/sets.....

and in regards to priviate (non public) vars in VBA class? Yes, 100% agree that me. should intel-sense those private members when writing code inside of the class.

Edit:

But, be it .net, or VBA?
Public vars do play nice with intel-sense, and that includes writing code inside, or outside of the class. And it also a nice "code smell", since then I can with ease determine which public members have code, and those that don't..........

It's a simple point here: I don't see much of any need nor advantages of building a geter/setter if you just setitng a value - make that var public, and you have intel-sense, and you have less code, and I can't really see any advantage in such cases to build that getter/setter.

Now, of course if you need other code, then of course build that getter/setter - it just "oh so often" people blind write out get/set code when no such code is required.....

R
Albert

 

[RonPaii]

I would argue that if you are lazy (and have MZTools) then creating accessors (let, get, set) for all class variables save a lot of coding time. With MZTools it takes a second to create the accessors from a class variable, but now coding is much faster especially with larger classes. I do not have to remember variable names, scroll up to the top to see what I called a variable, or type a variable. I simply type "Me." and intellisense takes over. Further there is a good chance that the accessor needs more code then simply setting or returning the value. There may be some checks in the accessor. So I might as well start with the stub to begin with.

However, for some reason there is a shortfall in vba that defeats good use of accessors. Maybe someone knows why that is. Unlike in .Net private accessors cannot be called inside the class as would be expected
If you type "Me." they do not show in intellisense
nor can you call them by Me.somePrivateProperty
This kind of defeats the whole purpose. You have to call it without Me.

The other thing that is annoying is In VBA, you cannot have a property with a private Let and a public Get directly. VBA's property accessors (Property Get, Property Let, and Property Set) must all be declared with the same visibility level—either all Public, all Private, or all Friend.

Is the issue with Get and Let, only with Interface properties? I use public and private properties all the time.

Public Property Get LastError() As Long
    LastError = m_Error
End Property
Private Property Let LastError(ByRef NewValue As Long)
    m_Error = NewValue
End Property

 

[MajP]

Is the issue with Get and Let, only with Interface properties? I use public and private properties all the time.

Interesting. I wonder when that was fixed. That used to be a problem. Glad to see it is no longer.

 

[MajP]

Is the issue with Get and Let, only with Interface properties? I use public and private properties all the time

More interesting is I asked Chat when this was fixed and Chat says it was always available. So maybe it was one of those urban myths that I assumed was true for year and never bothered checking. Which is grate because this is exactly a case where an accessor is useful.

 

[Albert D. Kallal]

Is the issue with Get and Let, only with Interface properties? I use public and private properties all the time.

Public Property Get LastError() As Long
    LastError = m_Error
End Property
Private Property Let LastError(ByRef NewValue As Long)
    m_Error = NewValue
End Property

As noted, not a huge deal anyway. But, as per above, I would have just made m_Error public - and then you don't need the Get/Let. It's a minor point on my part, and in a lot of cases, I skip the Get/Let, and just declare the var as public at the class level. As such, then the var is exposed, and intel-sense work. And I much often do the same in .net code.....

R
Albert

 

[bodders24]

Thanks again for your comments & explanations above. As I previously mentioned this app is only for my personal use, and I wanted to find out how I could better use class modules. I started off from the Rubberduck article on OOP and proceeded from there.

I built this class generator database in Access to create the class modules (Interface and Implementation) from the SQL Server tables. It has saved me a lot of time, and improved my (imperfect) knowledge along the way.

I'm happy to share it here - it's not the finished article, but it might be of use to someone out there. The SQL Server part is what I have been working so the Access side is currently incomplete.

Bodders

 

[sonic8]

However, if you are building .net COM objects, then often a public getter/setter is required - but that's not your use case here...

You might be pleased to hear that in current VB.Net you can create a real property by just adding the "Property" keyword to a Public variable declaration to get a full fledged Property without writing a getter/setter.

Public Property YourPropertyName as PropertyType

 

[Albert D. Kallal]

You might be pleased to hear that in current VB.Net you can create a real property by just adding the "Property" keyword to a Public variable declaration to get a full fledged Property without writing a getter/setter.

Public Property YourPropertyName as PropertyType

Nice tip to share! - And I often use the above.
And as such ? Well, VERY hard to make the "lazy" case that no getter/setter is required, since that's what your suggesting does anyway!

However, while in .net you can still just declare the var as public?
(but BETTER is to use your suggesting).

In VBA, you don't have those "one line" declares. So, then using a public var works well.
And as such, it does work fine in .net also.

However, in .net, one probably better off to try and stick to public properties, since a public var is seen as a public "field" and not a "property".
This will matter if one is using reflection (accessing properties by a given string).

In my web development, I fast became tired of typing or writing binding code (code to fill out controls on a web page).
After all, coming from Access land, we don't have to write (or even bother) with code that pulls data from a database, and fills out a form - it's all automatic.

So, I built two routines.
fLoader("div on web page", DataBaseRow).

So, above takes the one database row, and fills out the controls on that web page (no doubt nested inside of that one div).
And then I have the reverse.
fWrite("div on web page", DatabaseRow).

The above transfers the value(s) from the web page back into the database row. (and thus a database .save will then write back to SQL server).

However, in some cases, I don't want to pass a database row, but want to pass a class. So, I have a routines that f-load, and f-write to a class....

So, the problem?
From that class, do I want public vars (called Fields)?
From that class do I want public Properties?
From that class do I want public methods?

So, I decided to go with public Properties (I'm using reflection, and passing a "string name" of the property to get the value(s).

So ,that's why I stated that in some cases, one might prefer to use a REAL property in place of a simple public var (which is a field). So, in some cases, especially when using reflection, then what kind of public "thing" you want to expose from the class matters, and this is more in the context of .net, and not VBA.

Anyway - a good tip on your part to share here....

R
Albert

 

[MajP]

I built this class generator database in Access to create the class modules (Interface and Implementation) from the SQL Server tables. It has saved me a lot of time, and improved my (imperfect) knowledge along the way.

That is pretty interesting and a lot of work! I need to dig into this more.

 

[bodders24]

I know this is off topic, but I cannot find the rules for posting. I'm trying to start a new post but it keeps getting blocked - there are no links in it.

Thanks

Bodders