Reputation: 13196
I have one project which provides a service to the others, and the return value of the method that provides this service is String. Within that project, I use some named constants to represent special out of band values that are returned in lieu of expected or recoverable errors, otherwise the service returns an XML string.
Something like the following:
' modService.bas
const SERVICE_BADARG as String = "Unsupported argument."
const SERVICE_TOOMANY as String = "Too many Foos."
' cServiceProvider.cls
Private Function GetXMLString() as String
' generate and return XML string holding all sorts of generic stuff
End Function
Public Function PerformService(argument as String) as String
' do some stuff
If (some_condition = true) Then
PerformService = SERVICE_BADARG
Else If (some_other_condition = true) Then
PerformService = SERVICE_TOOMANY
Else
PerformService = GetXMLString()
I'd like to be able, from other projects, be able to get at these constants without redundantly defining them. If possible, I'd also like to avoid putting them in the class (where they will be duplicated unnecessarily) and to avoid making a property for each one.
They are all constants, none of them ever change.
Upvotes: 3
Views: 4309
Reputation: 1554
I know this is old, but in case anyone is still wondering... try this pattern:
Public Function SERVICE_BADARG() As String
SERVICE_BADARG = "Unsupported argument."
End Function
Public Function SERVICE_TOOMANY() As String
SERVICE_TOOMANY = "Too many Foos."
End Function
Or more compactly with colons to put stuff on the same line:
Public Function SERVICE_BADARG() As String: SERVICE_BADARG = "Unsupported argument.": End Function
Public Function SERVICE_TOOMANY() As String: SERVICE_TOOMANY = "Too many Foos.": End Function
You could see a constant as a function without arguments. The advantage is that a function can be public, so you don't have to create a DLL. It also gets around only being able to declare them before other functions. VB6 allows you to hide the brackets:
x = "error: " & SERVICE_TOOMANY
Select Case y
Case SERVICE_BADARG
z = "error: y is a bad arg"
Case SERVICE_TOOMANY
z = "error: y is too many"
End Select
The disadvantage is a little overhead, but this is typically negligible
Upvotes: 0
Reputation: 5689
Unfortunately, VB gives you no mechanism of embedding constants into DLLs for compile-time use. You would have to return properties, as you said you didn't want to do.
I would definitely use the BAS route, unless there is a reason against it. An alternative to this would be to create a type library, and define the string constants in there. To do this, you will have to learn ODL, and use the MkTypeLib.exe program which comes with VB6. Or, if you somehow have access to "Advanced Visual Basic 6.0" by Matt Curland, there is a tool which allows you to create type libraries.
Upvotes: 2
Reputation: 244772
Why not just define the constants in a CONSTANTS.BAS
module, and then include that in each project? That way, to VB it would look like the definitions were duplicated, but from your perspective as a developer and a maintenance programmer, the definitions would all be collected in a single place?
Another option would be to create a DLL that defined the constants, but that would make using the values of those constants more costly in all of your code because rather than being compiled directly into the object code, they would have to be retrieved from a call to an external DLL. That seems like overkill for something that is truly constant.
Consider that a "constant" value is not necessarily the same thing as a "read-only" value. A constant value, like pi, will never change, so there is really not much to be lost by duplicating those values. You won't ever need to go back in and change them. Read-only values (like your error message strings) might change, so they're not really constants. It might make sense to place those into a DLL. Especially since performance isn't all that critical when all you're trying to do is shown an error message.
Upvotes: 3