Обучение языку MQL4 под MetaTrader 4

[voldemar227]

помогите найти буфер в данном индикаторе для iCustom

В этом индикаторе буферы не используются..

[barney26]

помогите найти буфер в данном индикаторе для iCustom

В этом индикаторе буферы не используются..

как мне задать чтобы сов видел лини или открывал ордера на касании линий? :-?

[voldemar227]

помогите найти буфер в данном индикаторе для iCustom

В этом индикаторе буферы не используются..

как мне задать чтобы сов видел лини или открывал ордера на касании линий? :-?

Ищите советником линии по их именам, далее имея имена можно получить всю инфу ....

[mahahuha]

помогите найти буфер в данном индикаторе для iCustom

Тут нет буфера.
Все рисуется в функциях void SetLevel() и void TRO().
Что-бы вытащить из них данные можно их логику перенести в свой код, или же самому добавить буфер и писать в него нужные значения (имплементировать код в эти функции)

---

Добавлено: 06-04-2016 08:15:57

---

Уровни, при беглом осмотре, считаются в int start(), в цикле for - значение ds1. Оно затем уже передается в функцию для отрисовки линий. Отсюда можно вытащить в буфер.
Изменено 6 апреля, 2016 пользователем mahahuha

[deathmurder]

приветствую всех.

Есть индикатор который строит линию по данным из файла CSV. Если кинуть его на график, работает, а в тестере никак не хочет ни линию рисовать, ни буфер для советника выгружать. Что делать, чтобы в тестере отображалась полоса.

Код прикрепляю. Сразу скажу, код не мой. Я его только откомпилировал под новый билд МТ4

Спасибо всем кто скачал файл и пытался разобраться.

Путь к файлам для тестера отличается от пути для простой работы индикатора на счете. Нужно табличный файл переместить по пути tester/files

[VILNER]

привет,может кто нибудь написать кусок кода который закрывает все отложенные ордера,при закрытии по тейк - профиту последнего ордера

[voldemar227]

привет,может кто нибудь написать кусок кода который закрывает все отложенные ордера,при закрытии по тейк - профиту последнего ордера

Держите

//+------------------------------------------------------------------+
//+ Функция удаления всех отложенных ордеров если последний закрыт в плюс.
//+------------------------------------------------------------------+
bool LastProfitDeleteAll(string aSymbol="",int aMagic=0)
  {
   if(aSymbol=="")aSymbol=Symbol();

   int time=0; double his_profit=0;
   for(int i=OrdersHistoryTotal()-1; i>=0; i--)
      if(OrderSelect(i,SELECT_BY_POS,MODE_HISTORY))
         if(OrderSymbol()==aSymbol)
            if(OrderMagicNumber()==aMagic)
               if(OrderCloseTime()>time)
                 {
                  time       = (int)OrderCloseTime();
                  his_profit = OrderProfit();
                 }
// ---
   if(time>0 && his_profit>0)
      for(int i=OrdersTotal()-1; i>=0; i--)
         if(OrderSelect(i,SELECT_BY_POS))
            if(OrderSymbol()==aSymbol)
               if(OrderMagicNumber()==aMagic)
                  if(OrderType()>1)
                     if(!OrderDelete(OrderTicket()))
                       {
                        Print("Error N ",GetLastError());
                        return false;
                       }
   return true;
  }
//+------------------------------------------------------------------+

[JR]

Парни, новая задачка (для кого-то старая :)):
Есть мультивалютный сеточник, торгующий по сигналам на разных парах (несколько копий советника на разных парах), ну подобие ApM Grid. В советнике есть контроль максимума одновременно открытых в работе валютных пар, также есть контроль направления валют (например, если открыта покупка EURUSD, то сигналы по другим парам на продажу USD игнорируем.)
При резком движении одной валюты, может возникать одновременный сигнал по разным валютным парам, как например сегодня по канадцу - с разницой в секунду сработали OrderSend по USDCAD, AUDCAD и NZDCAD. Естественно, блоки контроля отработать не успели, одновременно открылись три пары в одном направлении.

Вопрос - есть ли эффективное решение, позволяющее контролировать такие ситуации? Как-то создать очередь в запросах, ввести таймер на открытие или что-то еще?

[Qj]

Парни, новая задачка (для кого-то старая :)) :
Есть мультивалютный сеточник, торгующий по сигналам на разных парах (несколько копий советника на разных парах), ну подобие ApM Grid. В советнике есть контроль максимума одновременно открытых в работе валютных пар, также есть контроль направления валют (например, если открыта покупка EURUSD, то сигналы по другим парам на продажу USD игнорируем.)
При резком движении одной валюты, может возникать одновременный сигнал по разным валютным парам, как например сегодня по канадцу - с разницой в секунду сработали OrderSend по USDCAD, AUDCAD и NZDCAD. Естественно, блоки контроля отработать не успели, одновременно открылись три пары в одном направлении.

Вопрос - есть ли эффективное решение, позволяющее контролировать такие ситуации? Как-то создать очередь в запросах, ввести таймер на открытие или что-то еще?

Я думаю вам стоит начать пользоваться Mutex или Semaphore, а вообще прочитайте про синхронизацию потоков средствами Windows API. Изменено 8 апреля, 2016 пользователем Qj

[0ll]

JR Вы в МТ4 торгуете? а то Qj про мультипоточность читать отправляет... Qj уже пора?
JR "с разницой в секунду" и "одновременно" - сильно разные понятия. В МТ4 совы должны работать в одном потоке последовательно ( очерёдность может быть разной ), т.е. следующая сова должна знать об открытии ордера предыдущей.

[voldemar227]

JR Вы в МТ4 торгуете? а то Qj про мультипоточность читать отправляет... Qj уже пора?
JR "с разницой в секунду" и "одновременно" - сильно разные понятия. В МТ4 совы должны работать в одном потоке последовательно ( очерёдность может быть разной ), т.е. следующая сова должна знать об открытии ордера предыдущей.

я думаю что в мт4 лучше всего вести мультивалютную торговлю из одного советника...
Ставить 3-5 советников они могут конфликтовать или открывать ордера параллельно...
При использовании одного советника с алгоритмом работы по разным парам, конфликтов и параллельности можно избежать, а точнее их просто не будет... Конечно если грамотный код ...

[0ll]

voldemar227 иногда это будет нелегко. С открытием/сопровождением ордеров проблем нет, а вот если входных параметров много и они разные ( для разных пар ) - проблема. Придётся делать 2 совы - одна для тестирования входных параметров по каждой паре, а другая чисто для торговли в мультивалютном режиме. Это я ещё про индикаторных сов не вспоминаю.
Как -то мы обсуждали возможности МТ4 и тогда однозначно решили, что одновременного ( в строгом смысле ) или параллельного открытия ордеров быть не может. Может что-то поменялось... если есть достоверные данные прошу высказать.

[JR]

JR Вы в МТ4 торгуете? а то Qj про мультипоточность читать отправляет... Qj уже пора?
JR "с разницой в секунду" и "одновременно" - сильно разные понятия. В МТ4 совы должны работать в одном потоке последовательно ( очерёдность может быть разной ), т.е. следующая сова должна знать об открытии ордера предыдущей.

Да, торгую в MT4. Как можно узнать что был запрос OrderSend от предыдущей совы?

[Qj]

JR Вы в МТ4 торгуете? а то Qj про мультипоточность читать отправляет... Qj уже пора?
JR "с разницой в секунду" и "одновременно" - сильно разные понятия. В МТ4 совы должны работать в одном потоке последовательно ( очерёдность может быть разной ), т.е. следующая сова должна знать об открытии ордера предыдущей.

Думаете все же что в один момент времени работает один советник? Просто по сообщению выше я начал сомневаться.

[dermitay]

что-то вы как-то все усложняете.
1. Понятное дело что все работает в одном потоке и одновременное открываться ордера не могут вобще в принципе, торговый поток один, я так понимаю все ордерсенды просто ставятся в очередь и обрабатываются при первой же возможности(говоря языком многопоточности - когдра ресурс освобожден предыдущим запросом)
2. Я пишу давно уже мультивалютные совы, все пары обрабатываются у меня в одном коде. Сложность обработки больших объемов данных(допустим пар 24) решается динамическим массивом структур, где элемент массива - это структура, в которой хранится все, что нужно по единичной паре, обязательным условием(как я считаю), нужно хранить еще в этой структуре имя символа, чтобы не запутаться в циклах. В ините заполняем этот массив стурктур как минимум запоминая символ.
То есть сама структура будет выглядеть как минимум вот так вот

struct am{
string sym;
................// остальные нужные элементы
int countBUY;
int countSELL;
int curCountOrders;
int preCountOrders;

int timeprev;

double preClose;
double curClose;

double preRSI;
double curRSI;
double distance;
double lastprice;
};

сам массив объявлется тоже очень просто:

am MainBase[];

вот и всё.

При обращении нужно помнить на каком элементе в массиве мы остановились, ну и вызов будет более сложным с точки зрения абстракций. Например MainBase[j].preRSI, где перед этим проверям в цикле что в MainBase[j].sym равен нужному нам символу.

Вобще это в одном из видеоуроков поднималось если мне память не изменяет.

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

Но тут опять же возникает очень много вопросов как это все будет работать в нормальном понимании многопоточного программирования. Первый код может освободать флаг и занимать его снова, вторые/третьи совы могут не успевать подхватывать изменение состояния флага и т.п. Как вариант, после освобождения флага делать задержку по времени в первом коде, чтобы вторая/третья сова успевала взять контроль на себя(причем чтобы уж совсем путанциы не было, например можно привязывать значение глобальной переменной занятость определенным кодом, ну например если равно ноль - флаг свободен, можно работаь первому коду, присваиваем переменной значение 1, остальные совы будут знать что 1 - это значит работает первый сов, если цифра два - второй сов, ну и так далее).

Вопрос про оредрсенд предыдущей совы - можно решить чтением комментария ордера(в коммент пихаем номер совы например), но и тут мы можем напороться на баг - ордерсенд первой совы отправил запрос на сервер брокера, вторая сова в коде прочитала все ордера и открытого предыдущей совой оредра не увидела, так как сервер брокера ордер еще не открыл, и тут вторая сова посылает свой запрос на открытие ордера - вуаля, получили баг. Как решить - опять же можно каждым ордерсендом засирать глобальные перменные и совами читать их.

Других идей у меня нет >:d

Изменено 9 апреля, 2016 пользователем dermitay

[0ll]

JR следующая сова должна увидеть уже открытый ордер в списке. Но придётся на каждом тике вызывать функцию пересчёта ордеров. Если контроль сова делала на каждом тике - отпишись.

Qj лично у меня пока не возникло сомнений в однопоточности МТ4...

dermitay согласен с Вами. Сам делал через классы, но как писал выше, совы бывают разные - не всегда удобно писать мультивалютную сову...
в МТ4 пока ордер не откроется все совы ждут. это синхронный процесс, так что бага не будет. Для задач JR коммент не нужен - важен сам факт открытия ордера по определённой паре.
Изменено 9 апреля, 2016 пользователем 0ll

[dermitay]

0ll, ты хочешь сказать что когда вызывается функция OrderSend(...) то все потоки всех сов стопятся и "ждут" ответа сервера?

что-то очень сильно сомневаюсь, я не знаю как насчет "тиков", но если ты код пишешь на "тактах" юзая OnTimer() с мелким таймером(в одну милисекунду) вместо OnTick(), то параллельные коды работают и выполняют логику вне зависимости от того что там посылает другой код. мой опыт основан на связках досок с FF плюс мои совы и вся эта каша в одном терминале. ОнТаймеру пофигу на тики вобще(и честно я не понимаю почему народ пишет код сов именно до сих пор на ОнТиках, это же архаизм по сути: ждать тика брокера по паре на которой брошен сов, чтобы прогнать свой код, а при мультиторговле так это вобще неадекватный крайне медленный обсчет всей кучи инфы по всем парам и огромная задержка при принятии решений логики кода).

[JR]

JR следующая сова должна увидеть уже открытый ордер в списке. Но придётся на каждом тике вызывать функцию пересчёта ордеров. Если контроль сова делала на каждом тике - отпишись.

В том-то и дело, что контроль работает на каждом тике. Но контроль проверяет уже открытые в рынке ордера. А тут получается, что с разницой в секунду пошли OrderSend от трех советников, естественно брокер открыл все эти сделки.

[voldemar227]

0ll, ты хочешь сказать что когда вызывается функция OrderSend(...) то все потоки всех сов стопятся и "ждут" ответа сервера?

что-то очень сильно сомневаюсь, я не знаю как насчет "тиков", но если ты код пишешь на "тактах" юзая OnTimer() с мелким таймером(в одну милисекунду) вместо OnTick(), то параллельные коды работают и выполняют логику вне зависимости от того что там посылает другой код. мой опыт основан на связках досок с FF плюс мои совы и вся эта каша в одном терминале. ОнТаймеру пофигу на тики вобще(и честно я не понимаю почему народ пишет код сов именно до сих пор на ОнТиках, это же архаизм по сути: ждать тика брокера по паре на которой брошен сов, чтобы прогнать свой код, а при мультиторговле так это вобще неадекватный крайне медленный обсчет всей кучи инфы по всем парам и огромная задержка при принятии решений логики кода).

Функции нужно грамотно использовать, нужно правильно проектировать советника.
Он таймер запущенный с периодом миллесекунд это то же не вариант, для серьезного советника с большими циклами таймер не вариант.
Например в коде советника есть цикл обсчета минутных баров 1440 *300 это 300 000 баров минимум , в терминале работает 5 копий советников при таймере в 100 миллесекунд это 50 выполнений в секунду, но тиков может прийти для всех копий советников 2-5 это 2-5 выполнений программы.
Исходя из таких вычислений использовать таймер не совсем хорошо...

---

Добавлено: 09-04-2016 11:28:01

---

voldemar227 иногда это будет нелегко. С открытием/сопровождением ордеров проблем нет, а вот если входных параметров много и они разные ( для разных пар ) - проблема. Придётся делать 2 совы - одна для тестирования входных параметров по каждой паре, а другая чисто для торговли в мультивалютном режиме. Это я ещё про индикаторных сов не вспоминаю.
Как -то мы обсуждали возможности МТ4 и тогда однозначно решили, что одновременного ( в строгом смысле ) или параллельного открытия ордеров быть не может. Может что-то поменялось... если есть достоверные данные прошу высказать.

1 Параметры можно передать хоть для 50 пар через файл тип CSV , советник считывает все данные для каждой пары и при этом с помощью CSV можно менять параметры на лету.
2 Можно заставить советника общаться с другими своими копиями через глобальные переменные ....

[0ll]

JR покажи свой код, который на каждом тике должен отрабатывать.

dermitay предлагаю эксперимент на проверку работы нескольких сов в 1/нескольких потоках:
делаем сову с таймером, который каждую мс проверяет время ( наверно можно локальное ). время задаётся в настройках совы ( чтоб не засрать принтами лог )
Как только время стало больше порога, принтуем символ + время + миллисекунды в лог и подвешиваем сову вычислением среднего кода символа какого-нибудь текста ( чтоб сова помучилась хоть с 5 мс ). после этого сову выгружаем и в онДеинит тоже принт с миллисекундами.
Запускаем сову на разных валютах с одним значением времени срабатывания и ждём. Ответ будет в логе. Я думаю будет что обсудить...

voldemar227 с загрузками внешних настроек через файл я в курсе об этом и писал...
А вот синхронизацию сов через глобальные переменные надо обсуждать - имеет ли смысл заморачиваться.
Если отправка ордера это синхронный процесс, то глобальные переменные не нужны. Если асинхронный, то без них ни как ( и то если все совы в одном потоке ).

[JR]

0ll, код смогу только на следующей неделе показать, сейчас в командировке, исходников под рукой нету. Но на самом деле, там ничего сложного, примерно выглядит так:
if (signal() && checkMaxTrades())
...открываем ордер в соответствии с сигналом

checkMaxTrades() - функция считает количество открытых пар в рынке (не так давно вместе писали тут ее) и возвращает true, если не превышаем количество в настройках.

signal () - логика такая: если есть сигнал по индикаторам, перебираем открытые в рынке ордера и проверяем на соответствие направлений с текущей валютной парой и нужным нам на открытие типом ордера. Если совпадаем - return (false).

Дело в том, что я довольно тщательно тестировал эту логику на спокойном рынке - отрабатывает четко. А когда почти одновременно возникает сигнал по нескольким парам - все и открываются, так как сова не видит открытых ордеров других пар, а OrderSend с них уже ушли.

Пока только такая идея в голову пришла: поскольку разница во времени между сигналами все равно присутствует, можно при поступлении сигнала, перед OrderSend устанавливать глобальную переменную в запрет, а после успешного открытия ордера - снимать запрет. Ну и соответственно контроль этой переменной во всех копиях советника, примерно как-то так:

if (signal() && checkMaxTrades()) {
if (!GlobalVariableCheck("denied"))
GlobalVariableSet("denied", 1)
if (OpenMarketOrder(функция открытия рыночного ордера) > 0)
GlobalVariableDel("denied");
} Изменено 9 апреля, 2016 пользователем JR

[0ll]

JR я понял. надо будет писать спец сову на исследование асинхронности открывания ордера в МТ.

[dermitay]

Oll, ты слишком все усложнил
JR, можно создать восемь глобальных перменных с именами:
AUD, CAD, CHF, EUR, GBP, JPY, NZD, USD

в ините каждой присвоить ноль, при посылании одной из сов OrderSend две из этих переменных ставить в единицу.
другие совы, прежде чем открыть ордер, мониторят эти переменные, если хотя бы одна валюта равна единице - ордер отсекается(я имею ввиду сранвение валют по паре, по которой ты хочешь открыть ордер, нутыпонил :d )
сова, открывшая ордер по паре и изменившая глобальные переменные, должна вернуть их в исходное состояние. вот тут уже вопрос, что будет являться тригерром для обнуления переменных. либо по таймауту, либо по какому-либо событию(новости, по паре, на которой открыт ордер, прошло уже столько-то пп после открытия ордера, смена значений управляющих индюков и т.д.), так как ты должен понимать, что если сова обнулит их по таймауту, то событие по другой сове может быть до сих пор активным - и ордер опять откроется но уже другой совой.

единственное на что ты можешь нарваться - это на то, когда оба кода будут пытаться поменять одну переменную, перед тем как ее менять, обязательно проверяй ее значение. но как говорит Oll в mt4 у нас все работает в одном потоке, то в принципе такой ситуации не должно происходить.

ЗЫ: и да, работа с оперативкой гораздо быстрее чем работа с файлами, так что даже и не думай юзать парсинг CSV и тому подобное при решении такой задачи, как у тебя. Изменено 9 апреля, 2016 пользователем dermitay

[0ll]

Oll, ты слишком все усложнил

:d Ну а как ещё проверить последовательно совы работают или параллельно?
В глобальную переменную я бы написал не просто 1, а направление открытия по валюте. Можно логику выстроить так, что например доллар с еврой продал, а с фунтом купил - диверсификация, однако.

[dermitay]

Oll, ты слишком все усложнил

:d Ну а как ещё проверить последовательно совы работают или параллельно?
В глобальную переменную я бы написал не просто 1, а направление открытия по валюте. Можно логику выстроить так, что например доллар с еврой продал, а с фунтом купил - диверсификация, однако.

читаешь мы мысли)))) да, это вопрос, охринительный такой вопрос, кто первый встал, того и тапки.
я вобще боюсь что может получиться так по тактам процессора:
1. первый код проверяет значение перменной, оно равно нулю
2. второй код проверяет значение перменной, оно равно нулю
3. первый код меняет значение переменной в единицу, открывает ордер
4. второй код меняет значение переменной в единицу(в мт4 пофигу на ее значение, он принудительно пеняет глобальную, даже если она уже равна этому значению), открывает ордер

как отследить что находится в пуле задач мт4?)))))))))))))))))))))))) видимо, писать дополнительную сову - оснастку, наподобие диспетчера задач винды(ну я думаю не надо поднимать что это такое, здесь итак все прошаренные сидят), который и будет управлять очередью.

все-таки корректнее все это дело запихнуть в один мультивалютный код(ну сесть один раз и за пару-тройку дней перенести всю логику на динамические структуры как я описал, знание классов тут не нужно) и, простите мой французский, не ипать себе моск. Изменено 9 апреля, 2016 пользователем dermitay