А как еще принимающая программа узнает о передачи сообщения в конкретный момент?
Чтением этого же ресурса. Отправитель и читатель никак не взаимосвязаны. Отправитель просто пишет свои данные. Читатель в любой момент может их получить. При этом коллизии исключены.
Чтением этого же ресурса. Отправитель и читатель никак не взаимосвязаны. Отправитель просто пишет свои данные. Читатель в любой момент может их получить. При этом коллизии исключены.
Этот вариант возможен, если сообщение не обладает статусом срочности. Если от своевременной передачи ничего не зависит.
НО. Если содержание сообщения и момент передачи являются важными, то для принимающей стороны, это не вариант.
Иначе, принимающая сторона должна постоянно обращаться к ресурсу ожидая своего сообщения. А это, - затратно.
Например:
1. Индикатор сообщает советнику о текущей цене того символа, на который он поставлен.
2. Индикатор сообщает советнику о событии пересечении уровня, который был установлен пользователем.
В первом случае, принимающая сторона может получить данные о тек.цене символа в любое удобное время.
Во втором случае, принимающая сторона не знает когда случиться событие, и вынуждена постоянно "просматривать почту".
Наверное, обладаете большим количеством времени расписывать столь подробно различные варианты взаимодействий. К сожалению, таким ресурсом не обладаю.
Вот статья на тему, где идет полное взаимодействие. Каждое здание строится из кирпичей и под конкретные задачи. Все возможные кирпичи показаны в самом начале ветки. Остальное - дело строителя.
Реализация торговых алгоритмов часто требует анализа информации из различных внешних источников, в частности из Internet. MQL5 предоставляет функцию WebRequest для отправки HTTP-запросов во "внешний мир", но она, к сожалению, обладает одним заметным недостатком. Эта функция является синхронной, а потому блокирует работу эксперта на все время...
// Пример передачи/обмена данных между программами через поле комментария чартов#include <fxsaber\HistoryTicks\Data_String.mqh> // https://www.mql5.com/ru/code/20298voidOnStart()
{
int ArrayIn[] = {0, 1, 2, 3, 4, 5};
ChartSetString(0, CHART_COMMENT, DATA_STRING::ToString(ArrayIn)); // Записали данные в комментарий чартаint ArrayOut[];
DATA_STRING::FromString(ChartGetString(0, CHART_COMMENT), ArrayOut); // Прочли данные из комментария чартаArrayPrint(ArrayOut);
}
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Суть в том, что если передавать маленькие сообщения через ресурсы, то сигнал о передачи все равно нужно передавать через EventChartCustom.
В том то и дело, что не нужно.
В том то и дело, что не нужно.
А как еще принимающая программа узнает о передачи сообщения в конкретный момент?
Но, еще раз повторю: для очень больших и редких сообщений, может быть удобнее и целесообразнее испльзовать файлы или ресурсы.
Здесь я согласен с fxsaber.
А как еще принимающая программа узнает о передачи сообщения в конкретный момент?
Чтением этого же ресурса. Отправитель и читатель никак не взаимосвязаны. Отправитель просто пишет свои данные. Читатель в любой момент может их получить. При этом коллизии исключены.
Чтением этого же ресурса. Отправитель и читатель никак не взаимосвязаны. Отправитель просто пишет свои данные. Читатель в любой момент может их получить. При этом коллизии исключены.
Этот вариант возможен, если сообщение не обладает статусом срочности. Если от своевременной передачи ничего не зависит.
НО. Если содержание сообщения и момент передачи являются важными, то для принимающей стороны, это не вариант.
Иначе, принимающая сторона должна постоянно обращаться к ресурсу ожидая своего сообщения. А это, - затратно.
Например:
1. Индикатор сообщает советнику о текущей цене того символа, на который он поставлен.
2. Индикатор сообщает советнику о событии пересечении уровня, который был установлен пользователем.
В первом случае, принимающая сторона может получить данные о тек.цене символа в любое удобное время.
Во втором случае, принимающая сторона не знает когда случиться событие, и вынуждена постоянно "просматривать почту".
Наверное, обладаете большим количеством времени расписывать столь подробно различные варианты взаимодействий. К сожалению, таким ресурсом не обладаю.
Вот статья на тему, где идет полное взаимодействие. Каждое здание строится из кирпичей и под конкретные задачи. Все возможные кирпичи показаны в самом начале ветки. Остальное - дело строителя.
Без политики, без обсуждения ситуаций в той, или иной стране и без флуда.
Флуд удалю, за остальное перечисленное неделя отдыха.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Библиотеки: HistoryTicks
fxsaber, 2018.12.04 09:11
Интересует возможность обмениваться данными между программами. Как можно быстро передать класс или структуру между советниками ???
Из своего опыта отвечу так:
в конечном счете это всё равно получится один советник, как самый лучший и удобный вариант для реальной торговли
в конечном счете это всё равно получится один советник, как самый лучший и удобный вариант для реальной торговли
Без индикатора-транслятора тиков не получается.