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

Carl Schreiber 2022.01.24 11:02 #11

Я заметил разницу между комиссией, взимаемой за позиции, и комиссией, взимаемой за сделки на моем счете с реальными деньгами. Чтобы узнать, где, как и почему это произошло, я распечатал всю историю счета в виде 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,76
Deals	199518759	2021.06.01 05:02:25	165890977	GBPUSD	sell	in	0.03	1,42411	199518759		0,00	- 0,07	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	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
Deals	199520000	2021.06.01 05:25:05	165891942	GBPUSD	buy	out	0.03	1,42373	199520000		0,00	- 0,07	1,86
Deals	199520056	2021.06.01 05:25:16	165891989	GBPUSD	buy	out	0.03	1,42380	199520056		0,00	- 0,07	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.

Новая версия платформы MetaTrader Новая версия платформы MetaTrader Новая версия платформы MetaTrader

TheXpert 2022.01.24 12:34 #12

Carl Schreiber #:

информация по позиции включает обе стороны - IN и OUT, сделка - это только одна из сторон

Carl Schreiber 2022.01.24 13:31 #13

TheXpert # :
информация по позиции включает обе стороны - IN и OUT, сделка - это только одна из сторон

Но разве комиссии по позициям не должны совпадать с комиссиями по сделкам (в совокупности)? Что делать, если это не так?

But don't commissions for positions have to match those of deals (in aggregate)? What to do if this is not the case?

Нужен ли режим тестирования странное условие брокера о Обсуждение статьи "Рецепты MQL5

TheXpert 2022.01.24 13:35 #14

Carl Schreiber #:

Но разве комиссии по позициям не должны совпадать с комиссиями по сделкам (в совокупности)? Что делать, если это не так?

должны, у вас на картинке совпадают

Maxim Kuznetsov 2022.01.24 13:49 #15

в другой ветке спрашивал, но ответа что-то нету...

новоявленные типы vector, matrix они как-то соотносятся с интерфейсами DLL ?

#import "mydll.dll"

bool checkit(matrix &matrx);

#import

возможно ли ? и во что выливаются

Slava 2022.01.24 14:42 #16

Maxim Kuznetsov #:

в другой ветке спрашивал, но ответа что-то нету...

новоявленные типы vector, matrix они как-то соотносятся с интерфейсами DLL ?

#import "mydll.dll"

bool checkit(matrix &matrx);

#import

возможно ли ? и во что выливаются

Пока никак нельзя передать матрицы и векторы в dll

Но такая возможность предусмотрена

fxsaber 2022.01.24 21:58 #17

Вопрос к сообществу. Есть такая функция.

// Выводит тикет ордера на 100-м месте в таблице ордеров истории.
void Func()
{
  if (HistorySelect(0, INT_MAX) &&     // Если удалось загрузить всю историю торгов
      (HistoryOrdersTotal() > 100))    // и в ней более 100 ордеров,
    Print(HistoryOrderGetTicket(100)); // Напечатаем ордер, который находится на 100-м месте в таблице ордеров истории.
}

Нормально ли, что данная функция при работе советника будет распечатывать разные тикеты? Просьба аргументировать.

[Удален] 2022.01.24 22:47 #18

fxsaber #:

Вопрос к сообществу. Есть такая функция.

Нормально ли, что данная функция при работе советника будет распечатывать разные тикеты? Просьба аргументировать.

Ордера в историю добавляются в конец списка, а значит добавление новых данных не должно влиять на то, какой будет ордер в 100 позиции. Но если загрузка истории каждый раз будет подгружать не всю историю (нулевой индекс не будет указывать на самый ранний ордерр) то и 100-й индекс каждый раз будет указывать на другой ордер.

Теперь встречный вопрос - что значит "Нормаьно" ? Нормально ли это для меня как для разработчика ? - Не очень - это вносит неопределенность, а её и так порой бывает с избытком.

Нормально ли это с точки зрения вероятности подобного исхода ? - да вполне.

Загрузка собственной истории, как -= !!! ПРАВИЛЬНАЯ РАБОТА Советники: Simple_Virtual_TP_SL

fxsaber 2022.01.24 23:40 #19

Mikhail Makhovskii #:

Ордера в историю добавляются в конец списка, а значит добавление новых данных не должно влиять на то, какой будет ордер в 100 позиции. Но если загрузка истории каждый раз будет подгружать не всю историю (нулевой индекс не будет указывать на самый ранний ордерр) то и 100-й индекс каждый раз будет указывать на другой ордер.

Параметры HistorySelect в предложенной функции четко указывают на всю историю.

Теперь встречный вопрос - что значит "Нормаьно" ? Нормально ли это для меня как для разработчика ? - Не очень - это вносит неопределенность, а её и так порой бывает с избытком.

Да, неопределенность. Таков MT5, к сожалению, даже в этом деле.

fxsaber 2022.01.24 23:43 #20

Mikhail Makhovskii #:

Ордера в историю добавляются в конец списка, а значит добавление новых данных не должно влиять на то, какой будет ордер в 100 позиции.

К сожалению, это неверное представление, хоть и полностью логичное, с точки зрения здравой архитектуры.

Новая версия платформы MetaTrader 5 build 3180: Векторы и матрицы в MQL5 и повышение удобства работы - страница 2