Enums registration and compiler complaints

SDKs Plugins
1

Here is an example of enums:

[code]// lex Python=SCLEX_PYTHON SCE_P_ SCLEX_PYTHON 2
// lex Nimrod=SCLEX_NIMROD SCE_P_ SCLEX_NIMROD 96
const char *SCE_P[] = {
“LEX_P_DEFAULT = 0”,
“LEX_P_COMMENTLINE = 1”,
“LEX_P_NUMBER = 2”,
“LEX_P_STRING = 3”,
“LEX_P_CHARACTER = 4”,
“LEX_P_WORD = 5”,
“LEX_P_TRIPLE = 6”,
“LEX_P_TRIPLEDOUBLE = 7”,
“LEX_P_CLASSNAME = 8”,
“LEX_P_DEFNAME = 9”,
“LEX_P_OPERATOR = 10”,
“LEX_P_IDENTIFIER = 11”,
“LEX_P_COMMENTBLOCK = 12”,
“LEX_P_STRINGEOL = 13”,
“LEX_P_WORD2 = 14”,
“LEX_P_DECORATOR = 15”,
};

// lex Cpp=SCLEX_CPP SCE_C_ SCLEX_CPP 3
// lex BullAnt=SCLEX_BULLANT SCE_C_ SCLEX_BULLANT 27
// lex CppNoCase SCLEX_CPPNOCASE 35
// ?? SCLEX_TAL 91
// ?? SCLEX_COBOL 92
// ?? SCLEX_TACL 93
const char *SCE_C[] = {
“LEX_C_DEFAULT = 0”,
“LEX_C_COMMENT = 1”,
“LEX_C_COMMENTLINE = 2”,
“LEX_C_COMMENTDOC = 3”,
“LEX_C_NUMBER = 4”,
“LEX_C_WORD = 5”,
“LEX_C_STRING = 6”,
“LEX_C_CHARACTER = 7”,
“LEX_C_UUID = 8”,
“LEX_C_PREPROCESSOR = 9”,
“LEX_C_OPERATOR = 10”,
“LEX_C_IDENTIFIER = 11”,
“LEX_C_STRINGEOL = 12”,
“LEX_C_VERBATIM = 13”,
“LEX_C_REGEX = 14”,
“LEX_C_COMMENTLINEDOC = 15”,
“LEX_C_WORD2 = 16”,
“LEX_C_COMMENTDOCKEYWORD = 17”,
“LEX_C_COMMENTDOCKEYWORDERROR = 18”,
“LEX_C_GLOBALCLASS = 19”,
“LEX_C_STRINGRAW = 20”,
“LEX_C_TRIPLEVERBATIM = 21”,
“LEX_C_HASHQUOTEDSTRING = 22”,
“LEX_C_PREPROCESSORCOMMENT = 23”,
“LEX_C_PREPROCESSORCOMMENTDOC = 24”,
“LEX_C_USERLITERAL = 25”,
“LEX_C_TASKMARKER = 26”,
“LEX_C_ESCAPESEQUENCE = 27”
};

#define SCOPE REALScopeGlobal
#define TYPE “”

REALenum Lexis_Enums[] = {
{ “LEX_P”, TYPE, SCOPE, SCE_P, _countof(SCE_P) },
{ “LEX_C”, TYPE, SCOPE, SCE_C, _countof(SCE_C) },
…
}; // 94 fields
[/code]

They are registered in a module

REALmoduleDefinition lexicalModule = { kCurrentREALControlVersion, "Lexes", LexingSharedMethods, _countof(LexingSharedMethods), Lexes_Constants, _countof(Lexes_Constants), nil, 0, // Properties nil, 0,//Lexis_Structs, _countof(Lexis_Structs), Lexis_Enums, _countof(Lexis_Enums), };

Code completion in the IDE shows, suggests, that it has been done correctly, yet the compiler tells when

me.ForeColor(Lexes.Lex_C.LEX_C_DEFAULT) = &c000000

“There is more than one item with this name and it’s not clear to which this refers.” The “me.ForeColor(Lexes.Lex_C.LEX_C_DEFAULT)” is highlighted in yellow. The same is happening when registering it globally:

REALRegisterEnum(&Lexis_Enums[1]);

Wanted to file as a feedback bug, but feedback fails to register with the server.

2

Can you show the code for your ForeColor method?

3

Ok, however, I am not sure if this is relevant…

// getters/setters of style elements { (REALproc) Lexing_ForeColor, REALnoImplementation, "ForeColor(styleNumber as Integer) As color" }, { (REALproc) Lexing_SetForeColor, REALnoImplementation, "ForeColor(styleNumber as Integer, Assigns color As color)" },

UInt32 Lexing_ForeColor(REALcontrolInstance instance, int styleNumber) { #ifndef WIN32 ScintillaView* editor = (ScintillaView *)LexGetView(instance); // return ConvertNSColorToUnit32([editor getColorProperty:SCI_STYLEGETFORE parameter: styleNumber]); return ScintillaColorToRealColor([editor getGeneralProperty:SCI_STYLEGETFORE parameter: styleNumber]); #else CScintillaView* editor = (CScintillaView *)LexGetView(instance); return ScintillaColorToRealColor(editor->getGeneralProperty(SCI_STYLEGETFORE, styleNumber)); #endif } void Lexing_SetForeColor(REALcontrolInstance instance, int styleNumber, UInt32 color) { #ifndef WIN32 ScintillaView* editor = (ScintillaView *)LexGetView(instance); // [editor setColorProperty:SCI_STYLESETFORE parameter: styleNumber value: ConvertUInt32ToNSColor(color)]; [editor setGeneralProperty:SCI_STYLESETFORE parameter: styleNumber value: RealColorToScintillaColor(color)]; #else CScintillaView* editor = (CScintillaView *)LexGetView(instance); editor->setGeneralProperty(SCI_STYLESETFORE, styleNumber, RealColorToScintillaColor(color)); #endif }

4

I think you should cast an integer on your enumeration value before calling the method:
me.ForeColor (Integer (Lexes.Lex_C.LEX_C_DEFAULT)) = &c000000

5

the definition of forecolor takes an integer not a Lexes.Lex_C

{ (REALproc) Lexing_SetForeColor, REALnoImplementation, “ForeColor(styleNumber as Integer, Assigns color As color)” },

why not make it

{ (REALproc) Lexing_SetForeColor, REALnoImplementation, “ForeColor(styleNumber as Lexes.Lex_C, Assigns color As color)” },

or as ulrich suggested call it by casting the enum to an integer

try the cast first & see if that fixes it if so then the change in declaration might be better

6

Interesting, the cast works; the pluginSDK says

[code]typedef struct REALenum // Jun 23 2006 – AJB (1)
{
// Specifies the name of the enumeration
const char *name;

// Specifies the type of the enumeration
// as an RB intrinsic datatype.
// eg) Integer or UInt8 (currently, integer
// types are the only types supported).  If
// you leave it blank, it means Integer
const char *type;

…
[/code]
I left it blank and thus the enum is an Integer; apparently, it is not. Anyway, thanks a bunch. Defining

"ForeColor(styleNumber as Lexes.Lex_C, Assigns color As color)"

is not an option, because then I have to define 94 different calls for “ForeColor”. I got to rethink this.

7

[quote=214016:@Alfred Van Hoek]Defining

“ForeColor(styleNumber as Lexes.Lex_C, Assigns color As color)”
is not an option, because then I have to define 94 different calls for “ForeColor”.[/quote]
There is no other way, as each enumeration is a separate thing.

8

[quote=214016:@Alfred Van Hoek]Interesting, the cast works; the pluginSDK says

[code]typedef struct REALenum // Jun 23 2006 – AJB (1)
{
// Specifies the name of the enumeration
const char *name;

// Specifies the type of the enumeration
// as an RB intrinsic datatype.
// eg) Integer or UInt8 (currently, integer
// types are the only types supported).  If
// you leave it blank, it means Integer
const char *type;

…
[/code]
I left it blank and thus the enum is an Integer; apparently, it is not. Anyway, thanks a bunch. Defining

"ForeColor(styleNumber as Lexes.Lex_C, Assigns color As color)"

is not an option, because then I have to define 94 different calls for “ForeColor”. I got to rethink this.[/quote]

The underlying type of the enumeration is Integer. The enumeration itself is still a distinct type of its own.

9

I understand. Strong typing is the basis of Xojo. I was hoping to register a bunch of enumerations instead of registering a bunch of modules defining the items as constants. I know that with kCurrentREALcontrolVersion = 13 these modules can be wrapped into a master module, but since this control needs to be at least backward compatible with kCurrentREALcontrolVersion = 11 the plugin will remain emitting 94 modules, which I do not like.

These were the underlying reasons to use enumerations. However, the enumerations require existing users to cast them into integers, and, in addition, they do not provide or show the integer value, unfortunately. Trying to sustain backward compatibility, while moving with Xojo is painstaking.

I appreciate the answers and insight given.

10

I don’t understand why you think that it should not be possible to have more than one enumeration in a module. In your code above you have LEX_P and LEX_C within the same module Lexes.

11

Eli, it is not my misunderstanding; I know that a single module can have a zillion enumerations. I wish I could let the plugin in the IDE to update existing projects by typecasting LEX_P, LEX_C, etc, to integers or that the Compiler or the IDE is way more informative, by saying “did you mean Integer(LEX_C.LEX_C_DEFAULT)?”. I hate the zillion modules, but 6 years ago, there was not a REALenum defined in the PluginSDK.