Новая версия платформы MetaTrader 5 build 3091: Улучшения в работе - страница 41

Новый комментарий
  
CustomSymbolSetDouble(symbol, SYMBOL_VOLUME_MIN, 1e-2); // 5308 Ошибочный параметр при установке свойства пользовательского символа
  
CustomSymbolSetString(symbol, SYMBOL_CURRENCY_BASE, "USD");
CustomSymbolSetString(symbol, SYMBOL_CURRENCY_PROFIT, "USD");
CustomSymbolSetString(symbol, SYMBOL_CURRENCY_MARGIN, "USD");

"Валюта прибыли = R" - что и почему?

Похоже название символа "VTBR"="VTB"+"R" - две валюты :D

Установка свойств сломана совсем... 

 

Продублирую тут из другой темы.

Некорректная работа с БД. Не работает селект по текстовому полю, при этом, если переделать текст запроса на поиск по PK, то запрос возвращает корректный результат.

Сову для воспроизведения прикрепляю. Результатом правильной работы  должен быть вывод в консоль "Found!"


2022.01.20 20:11:59.290	Terminal	Alpari MT5 x64 build 3144 started for Alpari International Limited
2022.01.20 20:11:59.291 Terminal        Windows 10 build 19043, 12 x Intel Xeon  E5-2620 v3 @ 2.40GHz, 8 / 15 Gb memory, 660 / 931 Gb disk, UAC, GMT+7
Файлы:
testDB_NW.mq5  8 kb
 
Косяк со свойствами кастомок даже через фейс "Создать символ"!
 
npats2007 #:

В справке по индикатору s iBandне совпадают индексы:

Примечание

Номера буферов: 0 - BASE_LINE, 1 - UPPER_BAND, 2 - LOWER_BAND


В коде примера:

Это несвязанные величины. Номера буферов индикатора iBands используются далее в функциях CopyBuffer().

 
Vasiliy Pushkaryov #:

Это несвязанные величины. Номера буферов индикатора iBands используются далее в функциях CopyBuffer().

Да. Ошибся. 

 

Я заметил разницу между комиссией, взимаемой за позиции, и комиссией, взимаемой за сделки на моем счете с реальными деньгами. Чтобы узнать, где, как и почему это произошло, я распечатал всю историю счета в виде XML-файла, а затем объединил таблицы Позиций и Сделок.

1.) Уже в этот момент я заметил, что таблицы сложно сделать совместимыми: отключить связанные столбцы, переместить много столбцов и создать новые столбцы - должно ли быть так? Это можно сделать более удобным для пользователя, если, например, важные данные (билет позиции, дата бронирования, ...) заполняются в тех же столбцах.

2.) В таблице сделок кажется, что номер тикета соответствующих позиций какой-то неправильный или другой для наших сделок, ни в коем случае не присваиваемый базовой позиции. Посмотрите на пример ниже с номером билета. 199518759 (2021.06.01 05:02:25 - 2021.06.01 05:25:16). Есть в-деле с делом нет. 165890977 (2021.06.01 05:02:25), но невыполненный 199520056 можно узнать только по метке времени (2021.06.01 05:25:16).

Это делает почти невозможным для пользователя проверку проводок с помощью отчета по счету, приходится неудобно создавать свою таблицу на MQL5. Вот пример двух смешанных позиций из позиций и сделок:

I noticed a difference in the commission charged for positions and the commission charged for deals on my real money account. To find out where and how and why this happened, I printed out the entire account history as an XML file and then combined the tables of Positions and Deals.

1.) Already at this point I noticed that the tables are difficult to make compatible: disconnect connected columns, move many columns and create new columns - does it have to be like this? This can be made more user-friendly, if e.g. the important data (ticket of the position, date of the booking, ...) are filled in the same columns.

2.) In the table of deals, it seems that the ticket number of the corresponding positions is somehow wrong or different for out deals, in any case not assignable to the underlying position. Look at the example below with ticket no. 199518759 (2021.06.01 05:02:25 - 2021.06.01 05:25:16). There is the in-deal with deal no. 165890977 (2021.06.01 05:02:25) but the out-deal 199520056 is only recognizable by the timestamp (2021.06.01 05:25:16).

This makes it almost impossible for the user to check the postings with the help of the account report, you have to awkwardly create your own table with MQL5. Here the example of two positions mixed from Positions and Deals:


Positions 199518759 2021.06.01 05:02:25 199518759 GBPUSD sell 0.03 1,42411
1,42317 2021.06.01 05:25:16 1,42380 - 0,14 0,00 0,76
Deals 199518759 2021.06.01 05:02:25 165890977 GBPUSD sell in 0.03 1,42411 199518759
0,00 - 0,07 0,00 0,00
Positions 199519318 2021.06.01 05:10:38 199519318 GBPUSD sell 0.03 1,42449

2021.06.01 05:25:05 1,42373 - 0,14 0,00 1,86
Deals 199519318 2021.06.01 05:10:38 165891449 GBPUSD sell in 0.03 1,42449 199519318
0,00 - 0,07 0,00 0,00
Deals 199520000 2021.06.01 05:25:05 165891942 GBPUSD buy out 0.03 1,42373 199520000
0,00 - 0,07 0,00 1,86
Deals 199520056 2021.06.01 05:25:16 165891989 GBPUSD buy out 0.03 1,42380 199520056
0,00 - 0,07 0,00 0,76



Особенно в денежных вещах важен контроль, и такие таблицы должны облегчать и поддерживать это, а не усложнять излишне, было бы неплохо, если бы это было улучшено.

Especially in money things control is important and such tables, should facilitate and support that and not make unnecessarily difficult, it would be nice if that would be improved.

 
Carl Schreiber #:

2.) В таблице сделок кажется, что номер тикета соответствующих позиций какой-то неправильный или другой для наших сделок, ни в коем случае не присваиваемый базовой позиции. Посмотрите на пример ниже с номером билета. 199518759 (2021.06.01 05:02:25 - 2021.06.01 05:25:16). Есть в-деле с делом нет. 165890977 (2021.06.01 05:02:25), но невыполненный 199520056 можно узнать только по метке времени (2021.06.01 05:25:16).

Тикет позиции равен тикету первого исполненного ордера (не сделки): POSITION_TICKET == POSITION_ID == FIRST_ORDER_TICKET == FIRST_ORDER_POSITION_ID.

Сам для анализа истории использую MQL-вариант отчета. Он такой же, как в MT4, при этом дает полное понимание, что происходило на торговом счете.

1...3435363738394041
Новый комментарий
Причина обращения: