Новая версия платформы MetaTrader 5 build 3180: Векторы и матрицы в MQL5 и повышение удобства работы - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я заметил разницу между комиссией, взимаемой за позиции, и комиссией, взимаемой за сделки на моем счете с реальными деньгами. Чтобы узнать, где, как и почему это произошло, я распечатал всю историю счета в виде 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:
Особенно в денежных вещах важен контроль, и такие таблицы должны облегчать и поддерживать это, а не усложнять излишне, было бы неплохо, если бы это было улучшено.
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.
информация по позиции включает обе стороны - 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?
Но разве комиссии по позициям не должны совпадать с комиссиями по сделкам (в совокупности)? Что делать, если это не так?
в другой ветке спрашивал, но ответа что-то нету...
новоявленные типы vector, matrix они как-то соотносятся с интерфейсами DLL ?
#import "mydll.dll"
bool checkit(matrix &matrx);
#import
возможно ли ? и во что выливаются
в другой ветке спрашивал, но ответа что-то нету...
новоявленные типы vector, matrix они как-то соотносятся с интерфейсами DLL ?
#import "mydll.dll"
bool checkit(matrix &matrx);
#import
возможно ли ? и во что выливаются
Пока никак нельзя передать матрицы и векторы в dll
Но такая возможность предусмотрена
Вопрос к сообществу. Есть такая функция.
Нормально ли, что данная функция при работе советника будет распечатывать разные тикеты? Просьба аргументировать.
Вопрос к сообществу. Есть такая функция.
Нормально ли, что данная функция при работе советника будет распечатывать разные тикеты? Просьба аргументировать.
Ордера в историю добавляются в конец списка, а значит добавление новых данных не должно влиять на то, какой будет ордер в 100 позиции. Но если загрузка истории каждый раз будет подгружать не всю историю (нулевой индекс не будет указывать на самый ранний ордерр) то и 100-й индекс каждый раз будет указывать на другой ордер.
Теперь встречный вопрос - что значит "Нормаьно" ? Нормально ли это для меня как для разработчика ? - Не очень - это вносит неопределенность, а её и так порой бывает с избытком.
Нормально ли это с точки зрения вероятности подобного исхода ? - да вполне.
Ордера в историю добавляются в конец списка, а значит добавление новых данных не должно влиять на то, какой будет ордер в 100 позиции. Но если загрузка истории каждый раз будет подгружать не всю историю (нулевой индекс не будет указывать на самый ранний ордерр) то и 100-й индекс каждый раз будет указывать на другой ордер.
Параметры HistorySelect в предложенной функции четко указывают на всю историю.
Теперь встречный вопрос - что значит "Нормаьно" ? Нормально ли это для меня как для разработчика ? - Не очень - это вносит неопределенность, а её и так порой бывает с избытком.
Да, неопределенность. Таков MT5, к сожалению, даже в этом деле.
Ордера в историю добавляются в конец списка, а значит добавление новых данных не должно влиять на то, какой будет ордер в 100 позиции.
К сожалению, это неверное представление, хоть и полностью логичное, с точки зрения здравой архитектуры.