About nested enumerations

 

 Hello, nice to meet you here, as this is my 1st post. On to the topic now :)

 I am currently building my first EA and I finally came along to program the order logic. At that time, I was looking at OrderSend() and similar and I realised that I should have to check what is the Execution Mode of my browser (market, request ...). Of course, I could have a chat with them or look at their site, but that seemed to be way easy (or painful, it depends on the quality of the site  :) ). So, after looking around the forum and the internet, Nested Enumerations there you are. I am new at programming, so while I like enumerations I have never used them much and I did not know that in C (my language of preference and my way to MQL) there are not such things such as nested enumerations. Anyway, I am not complaining, as I regard these situations as one more chance to gain knowledge.

And I am coming now to MQL. While I like the fact that Meq Quotes is attempting to build a logic for nested enumerations, I may say that I find the current approach quite not ready.  For example, lets consider the  enum 

ENUM_SYMBOL_INFO_INTEGER which has a member  SYMBOL_TRADE_EXEMODE. The type of the latter is not a constant, as in enums in C, but another enum called ENUM_SYMBOL_TRADE_EXECUTION. That one is the final enum in the tree, with four members of constant type. Now, I am willing to retrieve what is the execution mode. Actually, I am looking for the value that ENUM_SYMBOL_TRADE_EXECUTION is, so for the value that SYMBOL_TRADE_EXEMODE has. It 's getting confusing, but the logic is clear nevertheless. But let's see what is the proposed way of the MQL manual to retrieve the value

 

ENUM_SYMBOL_TRADE_EXECUTION execution_mode=(ENUM_SYMBOL_TRADE_EXECUTION)SymbolInfoInteger(Symbol(),SYMBOL_TRADE_EXEMODE)

 

I am getting 2 (market). But I am also getting 2 if I put ENUM_DAY_OF_WEEK instead of ENUM_SYMBOL_TRADE_EXECUTION. I tried ENUM_SYMBOL_INFO_INTEGER and it happens the same. So the only part of all code that is active is the SYMBOL_TRADE_EXEMODE, which IMO classifies to a bug. For what is worth, I use the next piece of code to retrieve the value of SYMBOL_TRADE_EXEMODE

 

ENUM_SYMBOL_INFO_INTEGER execution_mode=SymbolInfoInteger(Symbol(),SYMBOL_TRADE_EXEMODE);

MessageBox("Execution mode is "+execution_mode);

 

P.S. If I put a more straight forward 

 

ENUM_SYMBOL_INFO_INTEGER execution_mode=SYMBOL_TRADE_EXEMODE

 

 returns 33 instead of 2.  In conclusion, I believe that there is some work to be done regarding nested enumerations. I would propose a more easy way to declare variables out of them, especially if we are going to deal with multiple levels (more than 2) . For example, if we have the enumerations

 ENUM_SYMBOL_INFO{ENUM WEEK, ...}, then ENUM_WEEK  {ENUM_MONDAY, ENUM_TUESDAY, ...}, then ENUM_MONDAY {ENUM_HOUR}, then ENUM_HOUR{ENUM_MINUTE}

and we wanted to retrieve the current minute, I believe would suffice to program like 

 ENUM_HOUR current_minute=ENUM_MINUTE

with the ENUM_MINUTE type casting from enum to integer taking place compile time.

 best regards

 

SYMBOL_TRADE_EXEMODE is definitevely a constant identifier. ENUM_SYMBOL_TRADE_EXECUTION enumeration has no "nested" relation to that constant.

From my point of view the weak point is with

 ENUM_SYMBOL_INFO_INTEGER execution_mode=SymbolInfoInteger(Symbol(),SYMBOL_TRADE_EXEMODE);

which performs unexpected casting. But this kind of "autocasting" exists with object pointers in the MQL4 as well, so it is a consistent bug :)

 

Demos:

I like enumerations I have never used them much and I did not know that in C (my language of preference and my way to MQL) there are not such things such as nested enumerations.

Meq Quotes is attempting to build a logic for nested enumerations,

ENUM_SYMBOL_INFO_INTEGER which has a member  SYMBOL_TRADE_EXEMODE.

The type of the latter is not a constant, as in enums in C, but another enum called ENUM_SYMBOL_TRADE_EXECUTION.

I am getting 2 (market). But I am also getting 2 if I put ENUM_DAY_OF_WEEK instead of ENUM_SYMBOL_TRADE_EXECUTION.

ENUM_HOUR current_minute=ENUM_MINUTE

  1. Enumerations are names for constant integers. Period. Nothing else!
  2. There is no such thing as nested enumerations.
  3. It does not have a member. ENUM_SYMBOL_INFO_INTEGER is a data type, SYMBOL_TRADE_EXEMODE is one of those values (12.) Just like uint is a data type and has values 0, 1, 2, ...
  4. False. You call SymbolInfoInteger(string, ENUM_SYMBOL_INFO_INTEGER) where the string is a symbol. If the enum is the value SYMBOL_TRADE_EXEMODE then it returns an integer cast-able to one of the ENUM_SYMBOL_TRADE_EXECUTION values.
  5. You can not pass ENUM_DAY_OF_WEEK anywhere. It is an enum, a datatype. You can only pass a value (SUNDAY, MONDAY, ...) You can't call a function: function(int), you have to pass a value function(1);
  6. If you define ENUM_HOUR and ENUM_MINUTE as values from some enum, your "ENUM_HOUR current_minute=ENUM_MINUTE" is the equivalent of "2 current_minute=1" BOGUS.
 

Hello again, sorry for being late as I had some obligations and I was off my home for a while. 

 

So, to begin with, I am going to explain a little bit more what my point is regarding enumerations in MQL.

It is true that the manual refers to Enumerations as a group of named constants in this page https://docs.mql4.com/basis/types/integer/enumeration of type int 4 bytes long

But int this page https://docs.mql4.com/constants/environment_state/marketinfoconstants we can see a discrepancy: each member of various enums can be either a variable int, a float, double, string, datetime, even another one enumeration. For example, the member SYMBOL_SPREAD of the enum ENUM_SYMBOL_INFO_INTEGER is not a constant int but a normal variable int, which is changing time after time. Well, do not get me wrong. As I said in my previous post, I like the way MQuotes handles the enumerations, in the end. I, my self, prefer to regard enumerations as a grouping of finite elements - and not of an arbirtrary size (to begin with, which in it self is IMO the most useful feature of enums), of various types of elements, and not only to a grouping of constants, which also happens to have a name assigned to them.

 

My main concern as I said is the way this implementation gets ...implemented. My proposition is to have a specific name of a group accompanied by a desciption of type; so, i will give an example; in the page in the manual we can see

ENUM_SYMBOL_INFO_INTEGER  with a member SYMBOL_TRADE_EXEMODE. The latter has a type ENUM_SYMBOL_TRADE_EXECUTION and so on

 My proposition is to have 

SYMBOL_INFO_INTEGER, type: enumeration - - > SYMBOL_TRADE_EXEMODE, type: enumeration

                                                           - - > SYMBOL_VOLUMELOW, type: long

                                                           - - >  SYMBOL_SPREAD_FLOAT, type: bool    

and so on . That way we will not have to type each time ENUM_something. Imagine if we would have to write each time ARITHMETIC_INT variable=15, or ARITHMETIC_FLOAT=55.55 and similar. So, I am taking this to the service desk as I consider some misconceptions which are present as bugs.

best regards,

Demosthenes 

 
Demos: But int this page https://docs.mql4.com/constants/environment_state/marketinfoconstants we can see a discrepancy: each member of various enums can be either a variable int, a float, double, string, datetime, even another one enumeration.
No you do not. You see MarketInfo take the enumeration (column one.) A int (column two.) You see it return a double that must be cast to the appropriate return type (column three.) There is no discrepancy.
 

WHRoeder, regarding that page https://docs.mql4.com/constants/environment_state/marketinfoconstants I forgot to say that we have to scroll down a little bit and you will find the second table I am having as an example, and so on

best regards
Reason: