JDYoder Posted March 15, 2005 Posted March 15, 2005 Not sure what this would be called, but in VB.Net, is it possible to have some type of enum that is string based? For example, I'm tracking DataType in my program for some objects, which can be "Integer", "String", "Boolean", etc. I'd like to declare variable "X" of type "DataTypeFields". Then when I type "X = ", the intellisense will list all possible string items declared within "DataTypeFields". I can do this if "DataTypeFields" is an enum, but that has to be numeric. And in my case, doing that would be worthless, arbitrary, and a pain to convert from string to integer, and back when needed, just to get the intellisense to work. Any ideas? Quote
Administrators PlausiblyDamp Posted March 15, 2005 Administrators Posted March 15, 2005 (edited) Although enums are of an integer type (byte, int16, int32 etc.) they can easily be converted to and from a string representation. You can always convert to the string representation by using the .ToString method and click gives a short sample of how to go the other way. Edited March 2, 2007 by PlausiblyDamp Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
JDYoder Posted March 15, 2005 Author Posted March 15, 2005 That's what I'm doing now with a couple of functions, but I'm finding it to be somewhat of a pain to always have to remember when to call which. Not only between saving and displaying, but when I need to compare values at different points in the program, meaning I always have to make sure I'm either comparing integer to integer or string to string, depending on where I'm at. I had hoped VB.Net allowed for string-type enums so I could avoid this minor headache, but I guess not. Thanks for confirming my suspicions. Quote
IngisKahn Posted March 15, 2005 Posted March 15, 2005 It sounds like you may be better served by using a hash table. Quote "Who is John Galt?"
Administrators PlausiblyDamp Posted March 15, 2005 Administrators Posted March 15, 2005 Not entirely sure where your problem lies - any chance you could post some code to give a better idea what you are doing? Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
Moderators Robby Posted March 15, 2005 Moderators Posted March 15, 2005 A cheap way of getting string representation is to use a structure. Setup your Const String types and whatever they equal to in the struct. Quote Visit...Bassic Software
JDYoder Posted March 16, 2005 Author Posted March 16, 2005 >> It sounds like you may be better served by using a hash table. Don't now what this is, but I'm willing to look into it if you can tell me why and point me in the right direction. >> A cheap way of getting string representation is to use a structure. Setup your Const String types and whatever they equal to in the struct. Meaning I need to remember to type the structure name everytime, followed by "." at which point intellisense will pop them up? I thought about doing that with a class, but it still means a new programmer would have to know to reference that class (or structure) every time. Whereas now, by having all my vars declared as an enum, intellisense pop up just by hitting "=". However, it's still something to reconsider, assuming I'm understanding you. >> Not entirely sure where your problem lies - any chance you could post some code to give a better idea what you are doing? It's not so much a problem as it is a hassle. But if you're curious, I'm querying SQL Server via a stored proc that's returning some of our own defined types. So we not only have "Integer", "Date", etc, but "Amount", "Percent", "Rate", etc. I have to track these with every control on my report designer in the Tag field. So I have this... Public Enum RWFieldTypes ' Assign values rather than start with understood 0 since that equals nothing, which we don't ' want to be true. (Otherwise comparing to nothing would be the same as the first element.) DateField = 1 IntegerField = 2 DecimalField = 3 BooleanField = 4 TextField = 5 AmountField = 6 PercentField = 7 RateField = 8 End Enum Public Function RWFieldTypeToString(ByVal vFieldType As RWFieldTypes) As String Return Replace(vFieldType.ToString(), "Field", "") End Function Public Function RWFieldType(ByVal strFieldType As String) As RWFieldTypes Try Return System.Enum.Parse(GetType(RWFieldTypes), strFieldType & "Field") Catch ex As Exception Return 0 End Try End Function So when I want to store "Amount" in a Tag field, I need to call RWFieldTypeToString to convert AmountField to "Amount." (And there are a few reasons we don't store the number value in the Tag field, which I'll not bore you with.) Likewise, if I need to compare a field's type, I call RWFieldType to convert it back to a number so intellisense works, rather than have to rely on typing "Percent" (or whatever) throughout the code. So I don't like having to call these two global functions throughout my code, but I think it's what I have to do unless another solution comes along. So that's my "dilemma." Nothing major. Just annoying and not very elegant to my way of thinking. Quote
mskeel Posted March 16, 2005 Posted March 16, 2005 You could put all of that data into it's own class. That would prevent the global aspect of the two methods. So the class would consist of the enum and the two methods. At leas then everything would be in one place and not sprinkled about... Quote
JDYoder Posted March 16, 2005 Author Posted March 16, 2005 But then I'd just have to declare a global variable of that type, which would essentially be the same thing. Seems like six of one and half dozen of the other. Quote
mskeel Posted March 16, 2005 Posted March 16, 2005 You could declere the varialbe private and use accessor methods (properties) which would insulate the rest of your code from a type change. Then if you decided to impliment this using a hashtable in the future you would only change this class and you wouldn't have to change any of your other code. Right now if you started using a hashtable as someone suggested you might have to change more than just those two methods. It was just a thought. It may not be the most appropriate decision to make for your code and it does seem like, for all intents and purposes, it would be nearly equivelant. The only advantage would be additional information hiding, which it seems you have bought through the use of the enum, so it probably won't matter. Quote
IngisKahn Posted March 16, 2005 Posted March 16, 2005 Too bad you're not using C#. If you were then you could put this in a class and define implicit type conversion operators. Quote "Who is John Galt?"
JDYoder Posted March 17, 2005 Author Posted March 17, 2005 >> Too bad you're not using C#. If you were then you could put this in a class and define implicit type conversion operators. I've dabbled in C#, so I'm curious to know what exactly this is. Or is it really complicated to get into? Quote
IngisKahn Posted March 17, 2005 Posted March 17, 2005 Basically you just make 2 functions for converting your class to/from a string so you could use your class just like it was a string. Quote "Who is John Galt?"
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.