I would like to have a string enum in my class. you cant have a string enum, any suggestions on how to handle this?

maybe a class with read only properties? are there static classes in vba? Types that you dont have to instantiate?

No static classes. VBA is not a true OO language - I think classes were only bolted on in version 3 or 4 IIRC. You also can't nest classes, in case you were intending to do that.

How come you want string enums? If there are strings, they are not enumerations by definition.

pootle flump ur codings are working excelent.

Basicly i wanted to use for Account#s,, but they will have wild cards and groupings so they may be like:

1000234
100*222
234***8,380339

each of those lines will be a grouping for financial reporting

Ok.
Understand I am just trying to get a context on this.

Your account numbers have a meaning, they are like codes? So account numbers starting "234" and ending "8" have something in common?

pootle flump ur codings are working excelent.

you got it wild cards are there but not used so i would do an exact match on a string,

so say I have a entry:

acct# 600276*,607*,605*,606*,601*,602*,603*,6006762209
Debit 100000000
Credit 0

In a work book I will then need to find each the line in each sheet with that acct# (leading to next question, if i cant figure out how to do that )

Ok - we've left pure VBA (where I'm fairly strong) and got into Excel (where I'm not). Someone else should be able to pick this up now we know what your problem really is.

pootle flump ur codings are working excelent.

Mike,

Can you attach a simple example workbook so we can see all of this in context? This will be possible with formulas (probably array formulas), however a different design might improve things.



Just to pick up on the earlier discussion regarding VBA and OO programming.

VBA supports all of the main OO concepts except for inheritance. However, you will find a general trend (an exception, for example, is when working with userforms) that VBA developers prefer to work with a procedural-driven approach rather than a class-driven approach. This is due to state loss events. A state loss event will reset all static and module level variables, and it will destroy all the custom class objects you have created. I'm not aware of a complete list of state loss causes, but here's a starting point:
http://www.xtremevbtalk.com/showpost...60&postcount=1


Hope that helps...

Getting off topic here, but Colin - are you seriously saying that VBA supports polymorphism?
I'm happy to argue Encapsulation too, but it's less black and white.

EDIT - I'd simply say VBA is a procedural language with simple classes bolted on. It was not intended to be an OO language, so saying it isn't is not knocking it, it is simply stating the case.

pootle flump ur codings are working excelent.

Hi PF,
I apologise if my post was misleading - VBA does not support true polymorphism; I 'justify' my not excluding it because VBA does support interface polymorphism to a limited extent (obviously no overloading etc..). And abstraction and encapsulation in VBA are both ticked boxes for me.


This thread is a follow on from another one where Mike and I were discussing constructors and overloading in VBA.

Ok i will post a wks and all the code.