Issues related to custom symbols

[f.pap]

I frequently use custom symbols, as I prefer downloading data from reliable external sources rather than relying on data retrieved directly from the broker.

I appreciate the ability to programmatically create and update custom symbols using the MQL5 functions designed for this purpose. However, the goal of this post is to highlight several issues I have encountered, either bugs or missing features, in the MQL5 language (build 5370).

If there is a more appropriate place for this post, please let me know.

---

1) Inconsistent return values from CustomSymbolSet...() functions

In some cases, the functions CustomSymbolSetInteger(), CustomSymbolSetDouble(), and CustomSymbolSetString() return true even when they fail to set the value provided as an argument.

For example, the following two calls:

CustomSymbolSetString(<symbol>, SYMBOL_CURRENCY_BASE, "USD");

CustomSymbolSetString(<symbol>, SYMBOL_CURRENCY_PROFIT, "USD");

do not behave as expected (and do not return false) if the following call has been made beforehand with <value> equal to either SYMBOL_CALC_MODE_FOREX or SYMBOL_CALC_MODE_FOREX_NO_LEVERAGE, or left uninitialized (e.g., if the currency is set before the calculation mode):

CustomSymbolSetInteger(<symbol>, SYMBOL_TRADE_CALC_MODE, <value>);

In such cases, the base currency defaults to the first three characters of the symbol name, and the profit currency to the next three. This behavior is somewhat understandable for FOREX symbols, as they typically follow this naming pattern, but it should not be enforced. For instance, I should be able to create a custom symbol named myEURUSD and still correctly set its currencies. Currently, this is impossible: base currency would result in 'myE' and profit currency will result in 'URU'.

---

2) Side effects when setting properties

As a result, after setting any property, its value must be read back and verified against the intended one.

However, even this is insufficient, since setting one property can have side effects on others. For example, using the same currency case, if the calculation mode allows explicit currency settings, and we set the currencies manually, then later change the calculation mode to FOREX, the currencies are automatically overwritten.

This makes it difficult to ensure that all properties are correctly set as intended.

---

3) Missing programmatic access to some properties

Some properties that can be set manually or “theoretically” via a JSON file cannot be set programmatically, or at least I have not found a way to do so:

• SwapYearDay
• TickFlags
• TradeFlags
• MarginFlags
• PricesAllowNegative

There appear to be no corresponding CustomSymbolSet...() functions for these.

---

4) Properties not respected even when set manually

Certain properties, such as PricesAllowNegative, can only be set manually. If this property is set to 1 in the JSON file, the custom symbol will still be created with it set to false. Apparently, there is no way, even through a JSON file, to create a custom symbol with this property set to true.

(I already described this issue here https://www.mql5.com/en/forum/495525).

---

I didn’t want to be too tedious or verbose, so I limited this analysis to the most important points. However, I am available to expand on these topics and perform further experiments if needed.

[Alain Verleyen]

Ryan L Johnson #:

< Wrong link removed by moderator >

Don't forget to use the translation feature (national flags) in the upper right corner.

I would just repost it there. The Mods can delete this thread if they want to.

Please don't post irrelevant or misleading information.

English forum is perfectly fine to report bugs.

[Alain Verleyen]

f.pap:

I frequently use custom symbols, as I prefer downloading data from reliable external sources rather than relying on data retrieved directly from the broker.

I appreciate the ability to programmatically create and update custom symbols using the MQL5 functions designed for this purpose. However, the goal of this post is to highlight several issues I have encountered, either bugs or missing features, in the MQL5 language (build 5370).

If there is a more appropriate place for this post, please let me know.

---

To report bugs you need to post technical information in priority.

• The context (mainly the MT5 build use, and your computer config if relevant).
• Code to reproduce the issue(s).
• Logs to show the output your get from your code, or any error.

Text is fine provided with the above information, text alone will mostly be ignored.

[Ryan L Johnson]

Forum on trading, automated trading systems and testing trading strategies

Feature request MT5

Fernando Carreiro, 2025.02.17 17:24

MetaQuotes has never provided an official way to request features or report bugs.

Most users try to post in the Russian forum on the most recent topic about a MetaTrader release build, but most are ignored.

If you do try, please remember to write in Russian only (use auto translation).

[Alain Verleyen]

Ryan L Johnson #:

The official way is to post on the forum, whatever the language.

Posting on English or Russian forum changes nothing. Actually depending how involved people are busy it can even be better and faster on English forum.

[f.pap]

Here is the code of a simple script showing issues 1) and 2) explained above:

#property script_show_inputs

sinput string i_symbol  = "myEURUSD";    // Name of the custom symbol that must be created


void SetProperties(ENUM_SYMBOL_CALC_MODE mode)
{
  if (!CustomSymbolSetInteger(i_symbol, SYMBOL_TRADE_CALC_MODE, mode))
  {
    PrintFormat("Cannot set calc mode: Error code %u", GetLastError());

    return;
  }

  if (!CustomSymbolSetString(i_symbol, SYMBOL_CURRENCY_BASE, "EUR"))
  {
    PrintFormat("Cannot set base currency: Error code %u", GetLastError());

    return;
  }

  if (!CustomSymbolSetString(i_symbol, SYMBOL_CURRENCY_PROFIT, "USD"))
  {
    PrintFormat("Cannot set profit currency: Error code %u", GetLastError());

    return;
  }
}


void Print()
{
  Print("");
  Print("Calculation mode: ", SymbolInfoInteger(i_symbol, SYMBOL_TRADE_CALC_MODE));
  Print("Base   currency:  ", SymbolInfoString(i_symbol, SYMBOL_CURRENCY_BASE));
  Print("Profit currency:  ", SymbolInfoString(i_symbol, SYMBOL_CURRENCY_PROFIT));
}


void OnStart()
{
  // delete the custom symbol, if it already exists
  CustomSymbolDelete(i_symbol);

  // create the custom symbol
  if (!CustomSymbolCreate(i_symbol, "custom"))
  {
    PrintFormat("Cannot create '%s' custom symbol: Error code %u", i_symbol, GetLastError());

    return;
  }

  // set the properties for the FOREX calculation mode: this does not work
  SetProperties(SYMBOL_CALC_MODE_FOREX);

  Print();

  // set the properties for the FOREX calculation mode: this works
  SetProperties(SYMBOL_CALC_MODE_FUTURES);

  Print();

  // change the calculation mode: this has side effects on the base and profit currencies
  if (!CustomSymbolSetInteger(i_symbol, SYMBOL_TRADE_CALC_MODE, SYMBOL_CALC_MODE_FOREX))
  {
    PrintFormat("Cannot set calc mode: Error code %u", GetLastError());

    return;
  }

  Print();
}

The output of this script is:

Calculation mode: 0
Base   currency:  myE    --> incorrect, I wanted to set EUR
Profit currency:  URU    --> incorrect, I wanted to set USD

Calculation mode: 1
Base   currency:  EUR    --> Ok
Profit currency:  USD    --> Ok

Calculation mode: 0
Base   currency:  myE    --> just changing the calculation mode changed these two properties
Profit currency:  URU

Regarding issues 3) and 4) they cannot be reproduced by pieces of code: issue 3) is related to some JSON file properties for which I did not find any match with the CustomSymbolSet...() functions and issue 4) must be tested manually when creating a custom symbol via JSON file.

[Alain Verleyen]

f.pap #:

Here is the code of a simple script showing issues 1) and 2) explained above:

The output of this script is:

Reported to MQ devs. Though that seems minor issue and maybe to not even a bug but an undocumented feature.

[f.pap]

Alain Verleyen #:

Reported to MQ devs. Though that seems minor issue and maybe to not even a bug but an undocumented feature.

Actually, rather than being an undocumented feature, this is a limitation, since it requires that any custom symbol based on the EURUSD FOREX instrument (in my example) must have a name starting with 'EURUSD'.

Issue 4, on the other hand, is indeed a bug, because the PricesAllowNegative property in the JSON file is ignored. There is currently no way to create a custom symbol with this property set to true via a JSON file, or even via code, since there is no corresponding parameter available in the CustomSymbolSetInteger() function.

[Alain Verleyen]

f.pap #:

Actually, rather than being an undocumented feature, this is a limitation, since it requires that any custom symbol based on the EURUSD FOREX instrument (in my example) must have a name starting with 'EURUSD'.

Semantic discussion are not useful.

Issue 4, on the other hand, is indeed a bug, because the PricesAllowNegative property in the JSON file is ignored. There is currently no way to create a custom symbol with this property set to true via a JSON file, or even via code, since there is no corresponding parameter available in the CustomSymbolSetInteger() function.

I know but it can be done manually.

And in your other topic you reported negative prices was working anyway, I didn't check. Isn't that the case ?

Forum on trading, automated trading systems and testing trading strategies

Custom symbols with negative prices: PricesAllowNegative property of JSON file is ignored

f.pap, 2025.09.16 19:02

Strangely, I just performed some tests and it seems that negative price rates are imported correctly regardless of the value set for this property in the custom symbol properties, at least I can see negative prices displayed correctly on the chart.

[Stanislav Korotky]

Alain Verleyen #:

Reported to MQ devs. Though that seems minor issue and maybe to not even a bug but an undocumented feature.

Yes, they are features described in the algotrading book.

[f.pap]

Alain Verleyen #:

And in your other topic you reported negative prices was working anyway, I didn't check. Isn't that the case ?

I've noticed that negative rates appear to be imported and shown in the chart correctly regardless of the value of the PricesAllowNegative property. However, I still need to run more tests to verify whether an Expert Advisor functions properly with negative rates even when this property is set to false (I suspect something might not work as expected, otherwise the property would be useless).