Enumerator Name from Integer

I pass a dictionary to a function which one of the items is set to an enumerator indicating the type of transaction to process. I am trying to create a text log entry of each dictionary item. I know how to get the Integer of the enumerator but is there a way to obtain the Name without using a Select Case?

enumDBItem.User = 1
enumDBItem.Account = 2
enumDBItem.Site = 3

-----

  Dim sLog As String = "DBItem: " + Integer(item.Value("item")).ToText 
  For each dItem As xojo.Core.DictionaryEntry in item
    if dItem.Key <> "item" 0 then sLog = sLog + ", " + item.Key
  next

msgbox sLog

In this case, if I pass enumDBItem.Account to the function (as a dictionary item), I would like to set sLog to “DBItem: Account” instead of “DBItem: 2”

No.

You may be interested to create a feature request asking for inspection of enumerations.

This already exists: <https://xojo.com/issue/35963>

I’ve been complaining about this for years. It makes it difficult to write serialization libraries without it.

My first suggestion is to make a helper extension method that knows how to convert from the type to its string.

Protected Function ToString(extends ChartType as ChartTypes) As string Select Case ChartType //MOST COMMON FIRST FOR IMPROVED PERFORMANCE Case ChartTypes.PieChart return "PieChart" Case ChartTypes.BarChart return "BarChart" Case ChartTypes.AreaChart return "AreaChart" Case ChartTypes.LineChart return "LineChart" ... End End Function

Here’s another way I use when I don’t want to write the select case.
Every time I create an enumeration I actually create two methods now (This is an example for an Enum called AccountType)
One to return IN ORDER the list of all the string names (you do need to keep this list up to date)

Function AccountTypes() As string() return Array("AccountsPayable", "AccountsReceivable", "Bank", _ "CostOfGoodsSold", "CreditCard", "Equity", "Expense", "FixedAsset", "Income", "LongTermLiability", _ "NonPosting", "OtherAsset", "OtherCurrentAsset", "OtherCurrentLiability", "OtherExpense", "OtherIncome") End Function

And one to convert the enum to its string

Function toString(extends a as QBD.AccountType) As String dim v as Variant = a try dim options() as string = AccountTypes return options(v.IntegerValue) catch return "" end End Function

Sometimes I include a “NilOption” in my list. If so add this to the top and say “NilType” = -1,
That way they indexing of the other options still starts at 0 so they array matches up for their names.
This is also nice because you can fill a listbox with all the choices of an enum as well.

For i as integer = 0 to AccountTypes.ubound listbox1.addRow(AccountTypes(i)) next
And if you want to set the rowTags to be the actual enum values, you just cast “i” into your enum type.

At the very least Xojo should let us generate these two “special methods” and have them just automatically stay up to date. We could then manually pass all these Methods into a serialization class so it could resolve these types by name instead of int value.

[quote=238095:@Brock Nash]I’ve been complaining about this for years. It makes it difficult to write serialization libraries without it.
[/quote]
You cant write a generic “serialize anything” anyway - with or without this

Sure you can. I’ve done it. The only thing it doesn’t do is multi-dimensional arrays.
I just pass in anything I want and it converts it to JSON and i can pass that JSON back and it reverts it back into classes. The only thing it doesn’t currently do is circular references. It works with enums too, it just currently has to use the integer value.

No
You just made my point - You cant write a generic “serialize anything” anyway
And you certainly can’t unserialize generically since you cant create a class and its properties on the fly as you read the data in.

You HAVE to special case things - multidimensional arrays and cyclical object graphs
And you cannot serialize something and have another application open that & reconstitute the objects UNLESS it already contains those classes (gawd forbid they have not been stripped out as well)

The IDE does “serialize” and “unserialize” of your project - we basically use an interface on every class
Simple, effective & we can handle any data type - cyclical graphs, multi dim arrays, etc because each object knows how to deal with them for IT’S specific use case

There is some common code they all can use to read & write values to the various formats

[quote=238155:@Norman Palardy]No
You just made my point - You cant write a generic “serialize anything” anyway
[/quote]

To be fair, you CAN have a generic one do the cyclical references. I’ve just been too lazy to do add it to my library. And we could deserialize multidimensional arrays but the problem is you can’t assign a multidimensional array to a variant currently so you can’t use reflection to set the property on a class. Xojo throws a compiler error saying it can’t handle this type conversion.

So if the only thing a generic “serialize anything” class can’t do is multidimensional arrays (which are pretty uncommon and can be designed-out of any situation), then I would say we have one - since “serialize 99.99% of all practical cases” sounds stupid and overly verbose.

Or just say [quote=238133:@Norman Palardy]You cant write a generic “serialize anything” anyway[/quote]
Which is still true no matter how many “yeah but’s” you reply with

You code suits YOUR needs - but from our / my perspective its not something we could ship to YOU and have you be happy with it
IF Xojo included your code as part of the framework the only thing we’d get is “There’s a bug here I cant serialize …”
So its not complete or generic enough

That’s my point

FWIW - multi dimensional arrays aren’t uncommon
At least not in the user projects I’ve seen submitted as part of bug reports

So Xojo should fix the one bug with not being able to handle multidimensional arrays with variants/introspection and then
ship a built Xojo Seriailization class. Sounds like a no brainer considering all the utility it has.

  1. if it were a “bug” - design flaw maybe

  2. Correct serialization IS possible without this and can already be done in a way that handles every data type (see my previous remarks) We already do it in the IDE without introspection. Its implementation actually existed before introspection. You just dont want to do it that way :stuck_out_tongue: