OnDeinit (reason)

Новый комментарий
 

Здравствуйте! 

Сейчас в OnDeinit советника можно получить целое значение, определяющее одно из двух событий

REASON_CHARTCHANGE

3

Символ или период графика был изменен


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

 

REASON_SYMBOL_CHANGE

3

Период графика был изменен

REASON_PERIOD_CHANGE

33

Символ графика был изменен
Документация по MQL5: Константы, перечисления и структуры / Именованные константы / Причины деинициализации
Документация по MQL5: Константы, перечисления и структуры / Именованные константы / Причины деинициализации
  • www.mql5.com
//| get text description                                             | //| Expert deinitialization function                                 |
 

смысла нет

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

если не предполагаете обрабатывать полностью таймсерию , значит и нет смысла обрабатывать эту информацию по событию  OnDeinit 

 
Igor Makanu:

смысла нет

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

если не предполагаете обрабатывать полностью таймсерию , значит и нет смысла обрабатывать эту информацию по событию  OnDeinit 

то, что вы этим не пользуетесь, не говорит об отсутствии смысла )

Представьте сценарий, советник использует появление новой H1 свечи для установки подсказок входа (период советника), а пользователь смотрит на более мелкий график, допустим M15 (период пользователя). При переключении с периода советника на период пользователя и обратно, OnDeinit не нужен, а при смене символа на графике - нужен 

 
Nikolai Karetnikov:

то, что вы этим не пользуетесь, не говорит об отсутствии смысла )

Представьте сценарий, советник использует появление новой H1 свечи для установки подсказок входа (период советника), а пользователь смотрит на более мелкий график, допустим M15 (период пользователя). При переключении с периода советника на период пользователя и обратно, OnDeinit не нужен, а при смене символа на графике - нужен 

не вижу смысла обсуждать не правильное использование советников и индикаторов:

- советник торгует

- индикатор рисует

для советника есть смысл обрабатывать смену ТФ или символа, но обычно для ЕА важно найти свои открытые ордера и по ордерам можно, опять же, принять решение

для индикаторов нет смысла обрабатывать событие OnDeinit - все равно будет создана новая копия индикатора


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

если речь идет о создании интерфейса, то тоже вариантов особо нет -  кнопки, чекбоксы разлетятся по чарту после переключения ТФ/символа, нет смысла их передвигать, обычно их уничтожают и создают заново


если речь об непонимании,что рисовать быстрее и проще индикаторными буферами, чем графическими обьектами - тут я пасс, уже наломал копий - первое, что вспоминается - граф. объекты не работают толком в тестере, очень много допущений

  
string LastSymbol = NULL;
//+------------------------------------------------------------------+
void OnInit()
{
   if(LastSymbol == NULL)
   {
      Print("First run EA");
      LastSymbol = _Symbol;
   }
   if(LastSymbol != _Symbol)
   {
      Print("EA works on a new symbol !");
      LastSymbol = _Symbol;
   }
}
//+------------------------------------------------------------------+
void OnDeinit( const int Reason )
{
}
//+------------------------------------------------------------------+
void OnTick()
{

}
//+------------------------------------------------------------------
 
рациональное зерно в ваших рассуждениях, безусловно, есть. Да я и не говорил, что самостоятельно отследить смену символа невозможно ;) 
 

вот, пожалуй, что меня смущает в идее четкого разделения VMC модели на Советник и Индикатор.

Допустим, необходимо реализовать следующий алгоритм

1. При запуске советника на график наносятся 11 линий. Одна на текущем Bid, 5 линий вниз через каждые 10 пунктов, 5 линий вверх через каждые 10 пунктов. Сразу выполняется продажа и после сделки, линия должна быть стерта. Если Bid поднимается на уровень или выше линии сверху - очередная продажа, если Bid опускается на уровень или ниже линии снизу - очередная продажа и удаление линии с графика.

2. На покупку то же 11 линий по Ask и тот же алгоритм.

Как вы видите реализацию подобного алгоритма в конструкции "Советник торгует, Индикатор рисует"?

 
Nikolai Karetnikov:

Как вы видите реализацию подобного алгоритма в конструкции "Советник торгует, Индикатор рисует"?

никак если это из области тестирования ручных ТС - вернее тут только от фантазии и требований работоспособности в тестере

если это АТС, то графика тут не нужна - выставите необходимые отложенные ордера - они отобразятся на чарте


ЗЫ: можно еще в индикаторе создать 100500 input-переменных и столько же индикаторных буферов и вызывать этот индикатор из ЕА, даже без обработки этих значений - тупо рисовать десяток другой баров графическими буферами, если  input-переменная равна EMPTY_VALUE она и не отобразится

 
Igor Makanu:

никак если это из области тестирования ручных ТС - вернее тут только от фантазии и требований работоспособности в тестере

если это АТС, то графика тут не нужна - выставите необходимые отложенные ордера - они отобразятся на чарте


ЗЫ: можно еще в индикаторе создать 100500 input-переменных и столько же индикаторных буферов и вызывать этот индикатор из ЕА, даже без обработки этих значений - тупо рисовать десяток другой баров графическими буферами, если  input-переменная равна EMPTY_VALUE она и не отобразится

Это все очень интересно, спасибо! )

Думаю, что мне имеет смысл пересмотреть свой подход к разработке некоторых задач 

Новый комментарий