MetaTrader 5 Platform update build 3660: Improvements and fixes - page 8

[Carl Schreiber]

Here: https://www.mql5.com/en/docs/basis/preprosessor/compilation

the property strict is missing.

[Fernando Carreiro]

@Carl Schreiber #: Here: https://www.mql5.com/en/docs/basis/preprosessor/compilation the property strict is missing.

That property is only for MQL4. It is not part of MQL5, but it is ignored for the sake of compliance and backward compatibility.

[Carl Schreiber]

Fernando Carreiro #:

That property is only for MQL4. It is not part of MQL5, but it is ignored for the sake of compliance and backward compatibility.

Oh, I didn't know it, thank you :)

[Carl Schreiber]

It would be nice and convenient for the developers if the error codes were converted into simple ENUMS, since everything seems to be prepared:

Constant	Code	Description
ERR_SUCCESS	0	The operation completed successfully
ERR_INTERNAL_ERROR	4001	Unexpected internal error
ERR_WRONG_INTERNAL_PARAMETER	4002	Wrong parameter in the inner call of the client terminal function
ERR_INVALID_PARAMETER	4003	Wrong parameter when calling the system function
ERR_NOT_ENOUGH_MEMORY	4004	Not enough memory to perform the system function

and

Code	Constant	Description
10004	TRADE_RETCODE_REQUOTE	Requote
10006	TRADE_RETCODE_REJECT	Request rejected
10007	TRADE_RETCODE_CANCEL	Request canceled by trader
10008	TRADE_RETCODE_PLACED	Order placed
10009	TRADE_RETCODE_DONE	Request completed
10010	TRADE_RETCODE_DONE_PARTIAL	Only part of the request was completed

Instead of either having extra functions with the explanations (with the need to update them) to be printed or the need to look up each error code individually we were enabled to use simply:

Print(EnumToString(_LastError));

And instead of "4003" everybody would read: "ERR_INVALID_PARAMETER"

Right now the compiler refuses this: :(

'_LastError' - parameter for EnumToString must be an enumeration        EasyTradeEvent_INCL.mqh 22      55

[Dominik Egert]

Carl Schreiber #:

It would be nice and convenient for the developers if the error codes were converted into simple ENUMS, since everything seems to be prepared:

You could take a look at these two projects, maybe they satisfy your needs in this regard. (LibDebug, LibError) - Error Codes in MQL5 are not an enumeration, probably because you have also undefined error codes, like all the USER defined error codes. 

They are not even real "#define" values, as you cannot overwrite them, as it were currently necessary, because of some bug-fixing on Metaquotes behalf... - See this link here: Error-Codes fixed 

Anyways, I think an ENUM, which is in the end also just a switch-case statement to resolve to a string value, is not sufficient anyways, as the names of some error codes are not really helpful. - As an example: "ERR_CUSTOM_SYMBOL_NAME_LONG" does this refer to a LONG value or does this mean the name is to long??

If given only this information, it is not always clear, as you cannot always see the exact code location where the error is produced, and therefore you do not have the context. But when given the error description: "The name of the custom symbol is too long. The length of the symbol name must not exceed 32 characters including the ending 0 character." it is clear.

I understand why this is implemented the way it is, and btw, other APIs also implement their error codes not as an enumeration, but usually with "#define"... - Its up to you to handle resolution of error codes to human readable text.

EDIT:

"... cannot overwrite them" -> Is wrong, you can overwrite them, but you cannot "#undef" them.

[Peter]

Short question ...

Is it working as designed when the compiler does NOT complain about this:

ulong ticket = -1;

From the docs:

ulong

The ulong type also occupies 8 bytes and can store values from 0 to 18 446 744 073 709 551 615.

Even when I do a:

Comment("ticket:" + IntegerToString(ticket));

It will output "ticket: -1"

I'm not very experienced in mql.
But with some experience in rust, I was pretty surprised about this behavior.

Version: 5.00 Build 3683

[Fernando Carreiro]

Peter #: Short question ... Is it working as designed when the compiler does NOT complain about this: From the docs: Even when I do a: It will output "ticker: -1" I'm not very experienced in mql. But with some experience in rust, I was pretty surprised about this behavior. Version: 5.00 Build 3683

There seems to be an implicit typecast being done ...

void OnStart() {
   ulong ticket = -1;
   Print( ticket );
};

2023.05.14 15:35:03.245 TestCalc (EURUSD,H1)    18446744073709551615

[Carl Schreiber]

Dominik Christian Egert #:

You could take a look at these two projects, maybe they satisfy your needs in this regard. (LibDebug, LibError) - Error Codes in MQL5 are not an enumeration, probably because you have also undefined error codes, like all the USER defined error codes. 

They are not even real "#define" values, as you cannot overwrite them, as it were currently necessary, because of some bug-fixing on Metaquotes behalf... - See this link here: Error-Codes fixed 

Anyways, I think an ENUM, which is in the end also just a switch-case statement to resolve to a string value, is not sufficient anyways, as the names of some error codes are not really helpful. - As an example: "ERR_CUSTOM_SYMBOL_NAME_LONG" does this refer to a LONG value or does this mean the name is to long??

If given only this information, it is not always clear, as you cannot always see the exact code location where the error is produced, and therefore you do not have the context. But when given the error description: "The name of the custom symbol is too long. The length of the symbol name must not exceed 32 characters including the ending 0 character." it is clear.

I understand why this is implemented the way it is, and btw, other APIs also implement their error codes not as an enumeration, but usually with "#define"... - Its up to you to handle resolution of error codes to human readable text.

EDIT:

"... cannot overwrite them" -> Is wrong, you can overwrite them, but you cannot "#undef" them.

I have my own error.mqh, which also includes Windows errors, for example. But I'm preparing something for others, and in order not to be forced to include all the other stuff I've programmed myself, I had the idea how to display a kind of "error explanation" without much extra stuff, but much more informative than just a number. The simpler the better is my slogan.

And when you mention ERR_CUSTOM_SYMBOL_NAME_LONG you have to consider the context in which the error occurred - in this case it's not a double value I assume.

[Dominik Egert]

Carl Schreiber #:

I have my own error.mqh, which also includes Windows errors, for example. But I'm preparing something for others, and in order not to be forced to include all the other stuff I've programmed myself, I had the idea how to display a kind of "error explanation" without much extra stuff, but much more informative than just a number. The simpler the better is my slogan.

And when you mention ERR_CUSTOM_SYMBOL_NAME_LONG you have to consider the context in which the error occurred - in this case it's not a double value I assume.

Would you want to contribute to LibError?

[Carl Schreiber]

Dominik Christian Egert #:

Would you want to contribute to LibError?

I am working on an improved way of OnTradeTransaction() my preamble:

It is as usual: the nomal case of sending an order is easy
but its error handling is 100 times more complex and complicated :(

The functionality of MQ's Trade.mqh is nice but it is not ideal (fast)
in case of errors and it does not harmonize well with OnTradeTransaction().
OnTradeTransaction() is triggered from not at all to four times for one
trading act set by a trader :(

Several ideas are to be processed:
1) Find the single trigger of OnTradeTransaction() that matters.
2) If a order failed the request and the result are used to react.
   E.g. in case of requotes result has valid bid and ask which can be used to resend the order
   if the offset is not too big.
3) The magic number is used as an individual ID for the confirmation
   in OnTradeTransaction as sometimes the other IDs are missing :(
   Therefore the magic number is created by (ulong)TimeCurrent() which is
   enough if the trader (EA) doesn't send masses of orders at once.
4) When an orders was accepted by the server a function chkREQ() adds
   the reqest that was send to the array ReqCHCK for confirmation via
   OnTradeTransaction()
5) To pass required information some fields of the trade structs are misused
   like deviation. This way we do not need to declare, fill, administrate,
   and delete additional data structures. We use what already exists :)
6) Here we use OrderSendAsync() as the EA quickly returns right after the
   order was accepted by the server in order to prepare the tracking of the order.
7) If OrderSendAsync() failed chkFail() tries one or more times to heal the problem.
8) If OrderSendAsync() succeded chkREQ() is called to prepare the confirmation by
   OnTradeTransaction().
9) In OnTradeTransaction(), the first thing that is collected is information
   about the various IDs (tickets, magic,...), that are available because
   often these values are not assigned :(
10)Then we go through a complicated and heterogeneous braid of return codes
   of the structure MqlTradeResult and the types of the structure MqlTradeTransaction.
   
I wish there would be a simpler solution, but it would be up to MetaQuotes to offer a simple
way for an EA to manage a confirmation and an error detection and handling.
Let's hope and pray ;)

I would be glad if you join.

Ahh - if you want I can send you my error.mqh

Since for me, less is more, here my small err() (modified and not tested that way):

string err(int e = -1, int fromLine=-1) {
   if ( e==-1 && _LastError==0 ) return("");
   if ( fromLine>0 )
        return( StringFormat("L[%i] err:%i %s",fromLine,_LastError,ErrorDescription(_LastError)) );
   return( StringFormat("err:%i %s",_LastError,ErrorDescription(_LastError)) ); //
}