I'm quite sure, most of these things have already been posted, but must be already a long time ago (or I just used the wrong keywords when seeking for these entries )...
I like the possibilities to do Enumerations, but sometimes I'd like to have some more possibilities, like the following: I want to split long constant lists into more smaller areas for structuring, what about a command which continues enumeration beginning with the highest enumerated constant so far?
Michael Vogel wrote:... I want to split long constant lists into more smaller areas for structuring, what about a command which continues enumeration beginning with the highest enumerated constant so far?
It's possible since PB3.9x or am I missing something ?
Enumeration
#GadgetInfo ; Will be 0
#GadgetText ; Will be 1
#GadgetOK ; Will be 2
EndEnumeration
Enumeration #PB_Compiler_EnumerationValue
#GadgetCancel ; Will be 3
#GadgetImage ; Will be 4
#GadgetSound ; Will be 5
EndEnumeration
For free libraries and tools, visit my web site (also home of jaPBe V3 and PureFORM).
Enumeration
#GadgetInfo ; Will be 0
#GadgetText ; Will be 1
#GadgetOK ; Will be 2
EndEnumeration
Enumeration #PB_Compiler_EnumerationValue
#GadgetCancel ; Will be 3
#GadgetImage ; Will be 4
#GadgetSound ; Will be 5
EndEnumeration
You are right, even I wanted to get the highest value ever assigned to an enumerated constant so far - but when using a clear order of the enumeration blocks, your example will show exactly what I have asked for :roll:
So maybe the following example just shows my untypical way of coding - it should demonstrate it better now, what I have ment before
It would be easier if we could reassign #PB_Compiler_EnumerationValue to the same constant, i.e. #CurrentGadgetEnum = #PB_Compiler_EnumerationValue several times instead of using #CurrentGadgetEnum1, #CurrentGadgetEnum2, etc...
For free libraries and tools, visit my web site (also home of jaPBe V3 and PureFORM).
PS these macros should be integrated into the system (to get rid of rewriting the name also in endenumeration line), or it should be done into an include file... -- oi, next idea: maybe a certain file (PureBasic.pbi) should be included by default
Enumeration 1
#COLOR_RED
#COLOR_YELLOW
#COLOR_GREEN
#COLOR_BLUE
#COLOR_BROWN
#COLOR_BLACK
#COLOR_WHITE
#COLOR_ORANGE
#COLOR_PURPLE
EndEnumeration #TOTAL_COLORS
Global Dim ColorSet(#TOTAL_COLORS)
I've often had large enumeration lists and the only way that I've been able to make this work would be to do something like Global Dim ColorSet(#COLOR_PURPLE) because that would be the last one. But it gets messy: For x = 1 to #COLOR_PURPLE... Yes, I could use ArraySize(...) but having a constant is faster and easier to understand in many cases.
Randy
Maybe it's just a bunch of stuff that happens -- Homer Simpson
gnozal wrote:It would be easier if we could reassign #PB_Compiler_EnumerationValue to the same constant, i.e. #CurrentGadgetEnum = #PB_Compiler_EnumerationValue several times instead of using #CurrentGadgetEnum1, #CurrentGadgetEnum2, etc...
A constant that can be changed is not a constant.
It is time to think about the concept of compiler variables (in contrast to runtime variables). For example, #PB_Compiler_EnumerationValue looks like a constant, but it is not a constant. It is a compiler variable. Only at the point of compilation it is used like a constant.
I think PureBasic should introduce the concept of compiler variables (instead of offering "not really constant constants")...
True, that would work. I had forgotten about that little internal value. I could then, hypothetically, use #TotalCount = #PB_Compiler_EnumerationValue. I'll give that a shot.
[Edit] It actually returns the next one so if the last value is 4, #PB_Compiler_EnumerationValue will actually equal 5.
Still, I could deduct one from it during assignment. At least it it frees me from having to make sure that a value is always at the bottom of the list.
[End of Edit]
Thanks for that tip,
Randy
Maybe it's just a bunch of stuff that happens -- Homer Simpson
Nothing up to PB 5.0, and I can use the macro for the first constant as well. But when using 5.1, I'll get an error, that boolean expressions are not allowed without the new Bool function, but Bool's results are non-integer values and bring up another error message...
I don't like the following code, but it works at least: