Page 1 of 2
Named Enumerations
Posted: Wed Apr 14, 2004 7:23 am
by GedB
I would be great if enumerations could be named. If two separate enumerations have the same name, then they are combined by the compiler.
For example, in Include_File_1 I could have my main window and an about box:
Code: Select all
Enumeration Windows
#Main_Window
EndEnumeration
Enumeration Gadgets; main window
#StringGadget
#ButtonGadget
#EditorGagdet
EndEnumeration
; Lots of code implementing main window
Enumeration Windows
#About_Dialog
EndEnumeration
Enumeration Gadgets; about dialog
#StringGadget
#ButtonGadget
#EditorGagdet
EndEnumeration
;Lots of code implementing the about dialog
Then in Include_File_2 I might have my standard search and replace dialog
Code: Select all
Enumeration Windows
#Search_and_Replace
EndEnumeration
Enumeration Gadgets; Search and Replace dialog
#Find_String
#Replace_String
#Find_First_Button
#Find_Next_Button
#Replace_Button
#Replace_All_Buttion
EndEnumeration
There would be just two enumerations which contain all of the constants combined.
I don't think it would be too difficult to implement. The compiler could keep a list of all enumerations declared and keep note of the next available value for that enumeration.
Enumerations without a name could be given a default name, such as
_PB_Enum_1.
The immediate benefit of this would be that several VisualDesigner include files could be easily included without modification.
In fact, it would provide a clean, static alternative for handling any necessary ids across include files, making the creation of standard libraries easy.
This could be achieved using #PB_Any, which is a great new feature, but it does require additional coding to look after the dynamic ids returned. If the contents are static then this method would prevent any additional code clutter.
Posted: Wed Apr 14, 2004 7:27 am
by GedB
A logical progression from this might be to allow implicit enumerations. Ie. to allow constants to be used within an enumeration without declaring them, the same way that variables are implicitly created.
All WindowIds or GadgetIds could be automatically added to an implicit windows or gadgets enumeration.
Just thinking aloud.
Posted: Wed Apr 14, 2004 7:28 am
by GedB
One problem would be name clashes. These would, however, be caught at compile time and can be avoided using naming conventions within any libraries.
Re: Named Enumerations
Posted: Wed Apr 14, 2004 8:28 am
by helpy
GedB wrote:I would be great if enumerations could be named. If two separate enumerations have the same name, then they are combined by the compiler.
That would be relay very helpful!
cu, helpy
Posted: Wed Apr 14, 2004 10:13 am
by Fred
Yes, that's a good idea, I will implement it.
Posted: Wed Apr 14, 2004 10:44 am
by GedB

Great!

Posted: Wed Apr 14, 2004 11:52 am
by blueznl
love it!
Posted: Sun Mar 19, 2006 12:31 pm
by mdp
I strongly support the idea.
I understand with recent changes the syntax cannot be the one in GedB's proposal.
It could be something like
Code: Select all
Enumeration Class 0
#gadget_0 ;=0
#gadget_1 ;=1
EndEnumeration
Enumeration 123 Class 1
#window_0 ;=123
#window_1 ;=124
EndEnumeration
Enumeration Class 2
#image_0 ;=0
#image_1 ;=1
EndEnumeration
Enumeration Class 0
#gadget_2 ;=2
#gadget_3 ;=3
EndEnumeration
Is this possible/is this still in the plan?
Posted: Sun Mar 19, 2006 1:04 pm
by mdp
I should eat more fish

, or call FlushMind() more often
The solution, or a good workaround:
Code: Select all
Enumeration
#gadget_0 ;=0
#gadget_1 ;=1
#Enumeration_CLASS_0
EndEnumeration
Enumeration 123
#window_0 ;=123
#window_1 ;=124
#Enumeration_CLASS_1
EndEnumeration
Enumeration
#image_0 ;=0
#image_1 ;=1
#Enumeration_CLASS_2
EndEnumeration
Enumeration #Enumeration_CLASS_0
#gadget_2 ;=2
#gadget_3 ;=3
EndEnumeration
Posted: Sun Mar 19, 2006 1:58 pm
by mdp
The restriction-annoyance with my above is that you have to add a new constant for every enumeration, so you still have to keep track.
Code: Select all
#IMAGESCONST_0 = 0
Enumeration #IMAGESCONST_0
#img_a
#img_b
#IMAGESCONST_1
EndEnumeration
Enumeration #IMAGESCONST_1
#img_c
#img_d
#IMAGESCONST_2
EndEnumeration
Enumeration #IMAGESCONST_2
#img_e
#img_f
#IMAGESCONST_3
EndEnumeration
So, the feature request to give us an automation for several different "#PB_Compiler_EnumerationValue"s could still be on...
Or am I missing something? Maybe it is already possible in a way I did not see?
Posted: Sun Mar 19, 2006 2:28 pm
by Dare2
It would be interesting if someone has a good generic workaround for this.
I have tried something similar:
Code: Select all
Enumeration #GadgetsA
.. yada
EndEnumeration
#GadgetsB = #PB_Compiler_EnumerationValue
But you still have to be specific to the project, create all these extra constants, and keep the includes and things in a particular order.
GedB's idea is good and would make it possible to reuse, unchanged, general purpose includes.
Posted: Sun Mar 19, 2006 2:47 pm
by Killswitch
I've just scanned through this thread, but what's the point? Can you not just put all the constants in the same enumeration yourself?
Posted: Sun Mar 19, 2006 3:25 pm
by Dare2
This is just a "would be nice". It would be very nice.
Consider GedB's initial post and example.
You have some "blackbox" code that does some task and it needs constants. Each time you use the blackbox code these constants must be modded to conform to constants in the main code.
So your black box isn't quite as modular as you might like.
It is no biggie (to me). Just finesse.
BTW, #PB_Any can be useful here. But #PB_Any is not always the desirable way.
Posted: Sun Mar 19, 2006 3:49 pm
by mdp
@Killswitch
You can't always put all the consts in a single enumerator. This happens, for example, when your code is spread in many .pb files, each one having its gadgets, its images etc.
In that case, at the present moment, (allow me to quote Dare2 from above):
you still have to be specific to the project and
keep the includes and things in a particular order.
The tools mature, the programmers try to keep the pace: I'm trying to write better code

I agree this is not top priority, but (maybe - please contradict me if I'm wrong) it is a small contribute to elevating PB... If it's true that somebody stated that PB is not apt for big projects
Posted: Sun Mar 19, 2006 3:53 pm
by freak
I soo love crazy macros
Code: Select all
Macro NamedEnumeration(Name)
CompilerIf Defined(Enum_#Name#_10, #PB_Constant)
Enumeration #Enum_#Name#_10
CompilerElse : CompilerIf Defined(Enum_#Name#_9, #PB_Constant)
Enumeration #Enum_#Name#_9
CompilerElse : CompilerIf Defined(Enum_#Name#_8, #PB_Constant)
Enumeration #Enum_#Name#_8
CompilerElse : CompilerIf Defined(Enum_#Name#_7, #PB_Constant)
Enumeration #Enum_#Name#_7
CompilerElse : CompilerIf Defined(Enum_#Name#_6, #PB_Constant)
Enumeration #Enum_#Name#_6
CompilerElse : CompilerIf Defined(Enum_#Name#_5, #PB_Constant)
Enumeration #Enum_#Name#_5
CompilerElse : CompilerIf Defined(Enum_#Name#_4, #PB_Constant)
Enumeration #Enum_#Name#_4
CompilerElse : CompilerIf Defined(Enum_#Name#_3, #PB_Constant)
Enumeration #Enum_#Name#_3
CompilerElse : CompilerIf Defined(Enum_#Name#_2, #PB_Constant)
Enumeration #Enum_#Name#_2
CompilerElse : CompilerIf Defined(Enum_#Name#_1, #PB_Constant)
Enumeration #Enum_#Name#_1
CompilerElse
Enumeration
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
EndMacro
Macro EndNamedEnumeration(Name)
CompilerIf Defined(Enum_#Name#_1, #PB_Constant) = 0
#Enum_#Name#_1
CompilerElse : CompilerIf Defined(Enum_#Name#_2, #PB_Constant) = 0
#Enum_#Name#_2
CompilerElse : CompilerIf Defined(Enum_#Name#_3, #PB_Constant) = 0
#Enum_#Name#_3
CompilerElse : CompilerIf Defined(Enum_#Name#_4, #PB_Constant) = 0
#Enum_#Name#_4
CompilerElse : CompilerIf Defined(Enum_#Name#_5, #PB_Constant) = 0
#Enum_#Name#_5
CompilerElse : CompilerIf Defined(Enum_#Name#_6, #PB_Constant) = 0
#Enum_#Name#_6
CompilerElse : CompilerIf Defined(Enum_#Name#_7, #PB_Constant) = 0
#Enum_#Name#_7
CompilerElse : CompilerIf Defined(Enum_#Name#_8, #PB_Constant) = 0
#Enum_#Name#_8
CompilerElse : CompilerIf Defined(Enum_#Name#_9, #PB_Constant) = 0
#Enum_#Name#_9
CompilerElse : CompilerIf Defined(Enum_#Name#_10, #PB_Constant) = 0
#Enum_#Name#_10
CompilerElse
CompilerError "The Enumeration macro is too small, add more lines :p"
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
CompilerEndIf
EndEnumeration
EndMacro
NamedEnumeration(Gadget)
#Gadget_0
#Gadget_1
#Gadget_2
EndNamedEnumeration(Gadget)
NamedEnumeration(Window)
#Window_0
EndNamedEnumeration(Window)
NamedEnumeration(Gadget)
#Gadget_3
EndNamedEnumeration(Gadget)
Debug #Gadget_0
Debug #Gadget_1
Debug #Gadget_2
Debug #Gadget_3
Note that with these macros you can only have 10 enumerations in the same name class.
This can be easily solved by adding more compilerifs to the macro though, so no problem
