Советник исполняется только на половине приходящих тиков. Как учесть пропущенные? - страница 3

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

getch - кажется вы заблуждаетесь. Функция start выполняется на каждом тике, НО если идут тежелые вычисления (в функции start) то тогда тик будеть пропущен.

НО если вы смотрите результат тестера, то там действительно не все тики моделируются - да и иногда моделируются как попало.

 
getch:
Rosh, спасибо за советник. Но вы же сами понимаете, что это одно и то же. Вопрос определения значений OHLC цены Ask так и остается открытым. Советники не вызываются на каждом тике и это обоснованно. Официально-обнародованным механизмом контроля 100% тиков является только DDE со своими ньюансами. Я написал в предыдущем посте причины необходимости определения значений OHLC цены Ask. Уважаемые разработчики, прошу вас дать информацию получения 100% тиков, либо значений OHLC цены Ask без использования DDE. С Уважением.

Я этот вариант советника гонял сутки и не получил ни одной ошибки. Подождем до вечера (американской сессии).

 
Itso:

getch - кажется вы заблуждаетесь. Функция start выполняется на каждом тике, НО если идут тежелые вычисления (в функции start) то тогда тик будеть пропущен.

НО если вы смотрите результат тестера, то там действительно не все тики моделируются - да и иногда моделируются как попало.

Советник из пустой функции start() выполняется не на всех тиках.

Rosh:

Я этот вариант советника гонял сутки и не получил ни одной ошибки. Подождем до вечера (американской сессии).

Надо определить переменную first, как static.

 
getch:

Rosh:

Я этот вариант советника гонял сутки и не получил ни одной ошибки. Подождем до вечера (американской сессии).

Надо определить переменную first, как static.


Да точно, не на том уровне объявил. Надо же так ошибиться! Исправил, запустил заново.

 
Rosh, запустите советник на минутном таймфрэйме в одном из тех ДЦ, что были упомянуты в моем письме. Ошибки сразу пойдут.
 
Они и так идут. Тики поступают быстрее, чем отрабатывает функция start(), как я понимаю. Если через DDE такой проблемы нет, то значит надо идти этим путем.
 

Тики приходят пачками. И даже советник из пустой функции start() будет выполняться только на первом тике каждой пачки.

Через DDE можно получать 100% тиков благодаря присутствию в нем накопительного буфера.

Но простую задачу определения значений OHLC цены Ask решать через DDE - как-то странно.

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

С Уважением.

 
Зачем это?
 
Сейчас определить, была ли такая-то цена Ask или нет возможно только используя DDE, который имеет массу своих неприятных ньюансов. В терминале есть возможность получать данные OHLC цены Bid, которые используются в советниках, индикаторах и скриптах. Но нет возможности получать (кроме как хитрыми и не очень надежными способами через DDE) такие же данные для цены Ask.
 
Integer:
Зачем это?

Я тоже присоединяюсь к просьбе, мне нужны для обработки все тики. Но по другой причине. Отслеживаю интенсивность потока.

Подтверждаю: 1 вариант Rosh (без статик - ошибок нет). Второй вариант идут ошибки ((. Сборщик тиков компостера наверное тоже из-за это пропускает, т.к. количество тиков не совпадает с историей.

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