Is it possible to universally instantiate a class?

[Dr. Demento]

I've been using bad programming form for a number of years by using an EXCESSIVE number of global constants (I used to get Out of Memory errors running the smallest sub; it's better now but still happens). After learning about classes, I was able to move the majority of the global constants to my class modules.

However, now every time I want to access anything in those class modules I have to instantiate it first; I've set up two global variables but they don't point to the class until I assign them (I'm explaining myself to people with huge amounts of experience compared to me ). I've tried Set in ThisWorkbook module; nope! I've tried defining them in a commonly used procedures that occur at startup; hard nope! I want to avoid instantiation everywhere the class is used because of the ubiquity of how I was using the global constants; instead, I'd like a one and done.

I found this article (3 Ways to Create Class Instances in VBA) and I think that addresses my problem but being a noob to classes, I'm not entirely sure. I also don't understand the implications of the limitation listed, so if someone could educate me, I'd appreciate it.

I can't use Rubberduck, as I use the class at work.

Thanks, y'all.

 

[Jaafar Tribak]

I am not sure I understand how constants inside a class could be used universally.

As you know, a Class is like a template on which an object is based. The code inside a Class is executed by clients of the Class via the Class Properties and Methods. Any Class constants or private routines can't be directly accessed by the Class clients. (unless you wrap them inside Properties or Methods)

I want to avoid instantiation everywhere the class is used because of the ubiquity of how I was using the global constants; instead, I'd like a one and done.

One Class instantiation produces one object only (unless you instantiate recursively inside the class but, that would be complicated) ... If you store the object in a variable at the top of a regular module and make it Global\Public, the class instance (object) can be seen and accessed throughout the entire vbaproject.

 

[Dr. Demento]

I have made everything that was a constant into a Property.

Property Get font_path() As String: font_path = "C:\Windows\Fonts\": End Property

It's an ugly hack, but by defining them within a class, I can then call upon any property (prior constant) and not have it overwhelm my meager memory.

 

[Jaafar Tribak]

I have made everything that was a constant into a Property.

Property Get font_path() As String: font_path = "C:\Windows\Fonts\": End Property

It's an ugly hack, but by defining them within a class, I can then call upon any property (prior constant) and not have it overwhelm my meager memory.

I don't exactly understand why constants would be affected by memory but if wraping them inside Properties as suggested works for you then ok. ... Maybe you should consider redisigning your code.
I am sure you are aware that you can make constants (or any value) persist just by simply temporarly storing them somewhere like in a worksheet cell or an Excel Name etc

 

[Dr. Demento]

It was more that the sheer number of public constants (some are extremely large, with 100's of terms each) chewed up so much memory, I would get out of memory errors.

Appreciate the thoughts; not too keen on re-vamping my code, but I'm always on the look out for doing things better.

Thanks, Jaafar.

 

[RoryA]

I have no idea what you mean by constants "with 100s of terms each"?

To avoid having to instantiate your class, you'd use the predeclaredid attribute mentioned in the article. You might also try putting your property procedures into a normal module.

I tend to agree though that it sounds like your code design needs a serious rethink.