Option Explicit, the
msoGraphic identifier in that property scope is a
Variant/Empty; there's an implicit type conversion happening when you do this:
If msoGraphic = 0 Then
vbEmpty will equate to
0, or even
"", but that's after converting to a comparable type (
String). There's a better way.
If IsEmpty(msoGraphic) Then
IsEmpty function will only ever return
True when given a
Variant/Empty value - which is exactly what we're dealing with here.
I could of course have just re-declared msoGraphic as a constant with value 28, but best practice seems to be that you should avoid using the actual value and use the enumerate constant instead
One doesn't exclude the other. If you define a public constant in an appropriately named standard module (e.g.
OfficeConstants), and use it, then you are adhering to the best practice. What happens then is deliberate shadowing of the
MsoShapeType.msoGraphic declaration - something Rubberduck would normally warn about, but with a descriptive
@IgnoreModule annotation comment, the intention is clarified, and the static code analysis tool knows to ignore them - and with a link to the official documentation, you ensure the values correctly match the actual documented underlying values for each identifier:
'@IgnoreModule ShadowedDeclaration: these constants are only available in Office 2016+
Public Const msoGraphic As Long = 28
What you want to avoid, is code like this, where
28 is some magic value that has no clear meaning:
If shapeType = 28 Then
Does this seem like the best way to handle this situation?
The problem is that you can't name your property
msoGraphic (well you could, but then you'd have to fully-qualify the
msoGraphic constant, and then that wouldn't be compilable, even without
Option Explicit), so any code (hopefully with
Option Explicit specified) that means to use the name
msoGraphic now needs to use
myMsoGraphic instead, and that isn't ideal, because it adds to the overall cognitive load: you, future you, and eventual maintainers have to remember to avoid
msoGraphic and use
myMsoGraphic instead, whereas with a
Public Const in a standard module that hides/shadows the constant from the referenced PowerPoint library when it exists, usage is much more seamless.
That said, while VBA is case-insensitive, a
camelCase public member clashes with the naming convention of pretty much everything else in your standard libraries - enum members only have a lowercase prefix as a namespace surrogate; every type, method, member, property, procedure, function, constant, in every standard library, uses
PascalCase. There's no reason to not make every single one of your own procedures use this naming convention too; also while the
my prefix is ubiquitous in so many VB examples, it's not a good prefix to use in actual code.
One last thing:
in case the value gets changed at some point in the future
MsoShapeType is defined in a shared Office library that isn't only referenced by PowerPoint projects - VBA is ridiculously backward-compatible (line numbers,
DefBool keywords, to name a few should-be-extinct-but-aren't-because-backward-compatibility still-supported language features): there is no way any constant ever released into the wild is ever going to get a new value in any future release. Not going to happen.