0 - Ждём следующей итерации, чтобы проверить и (или) построить таймсерию
> 0 Строим таймсерию
Из вашей справки я понял, что ВЫ почти так и сделали, оказывается нет.
Видимо один программист начинал писать, а кто-то другой закончил
Ваша реализация хороша для ФОРЕКС, но очень неудобна для ФОРТС.
На ФОРТС котировки могут долго не приходить, а таймсерия выгружается из паияти
и приходится весь процесс получения данных повторять снова, причём с заходом на сервер!
Для работы с данными множества символов используйте экспертов, все будет удобно и просто. Индикаторы в среде МТ5 в первую очередь рассчитаны на быстрый расчет по данным своей таймсерии и отображение результатов расчета на чарте. В процессе развития платформы они получили множество функций доступных экспертам, но базовые архитектурные ограничения остались. И нет никаких оснований полностью стирать отличие индикаторов от экспертов. Еще раз напоминаю, что самое существенное отличие заключается в наличии у экспертов собственного потока обработки. Расчет индикаторов происходит в служебном потоке, и этот поток выполняет множество других функций. Именно поэтому даже общий с экспертами функционал имеет разную реализацию.
Что касается доступа к истории, то универсального решения тут нет. Терминал заранее не может предсказать желание потребителя, т.е. хочет ли эксперт получить только одну дату или хочет запросить всю доступную историю. В терминале сделан выбор в пользу быстрого доступа к таймфрейму, т.е. по запросу пользователя делается попытка закэшировать актуальное (синхронизированное с сервером) состояние истории в полном объеме. Делается ставка на повторный активный доступ. Да, есть класс приложений где этот подход не удобен. Но если программист не будет зацикливаться на требованиях переписать терминал "лично под себя", то найдет решение в имеющемся функционале. Если решения нет совсем, то вот только тогда встает вопрос расширения функционала.
Описывайте конкретную проблему с конкретным кодом, без обобщений. Иначе получается, что непонятый функционал одной единственной функции раздувается до "все не так" и "все неудобно".
Для работы с данными множества символов используйте экспертов, все будет удобно и просто. Индикаторы в среде МТ5 в первую очередь рассчитаны на быстрый расчет по данным своей таймсерии и отображение результатов расчета на чарте. В процессе развития платформы они получили множество функций доступных экспертам, но базовые архитектурные ограничения остались. И нет никаких оснований полностью стирать отличие индикаторов от экспертов. Еще раз напоминаю, что самое существенное отличие заключается в наличии у экспертов собственного потока обработки. Расчет индикаторов происходит в служебном потоке, и этот поток выполняет множество других функций. Именно поэтому даже общий с экспертами функционал имеет разную реализацию.
Что касается доступа к истории, то универсального решения тут нет. Терминал заранее не может предсказать желание потребителя, т.е. хочет ли эксперт получить только одну дату или хочет запросить всю доступную историю. В терминале сделан выбор в пользу быстрого доступа к таймфрейму, т.е. по запросу пользователя делается попытка закэшировать актуальное (синхронизированное с сервером) состояние истории в полном объеме. Делается ставка на повторный активный доступ. Да, есть класс приложений где этот подход не удобен. Но если программист не будет зацикливаться на требованиях переписать терминал "лично под себя", то найдет решение в имеющемся функционале. Если решения нет совсем, то вот только тогда встает вопрос расширения функционала.
Описывайте конкретную проблему с конкретным кодом, без обобщений. Иначе получается, что непонятый функционал одной единственной функции раздувается до "все не так" и "все неудобно".
Добрый день, Антон!
Давайте "разберём" Ваш ответ:
1. "Для работы с данными множества символов используйте экспертов, все будет удобно и просто."
Мне нужна история (close) по 3-м символам с отображением на чарте.
Из советника есть другой способ получения истории по close?
И нужно "городить огород", чтобы нарисовать результаты из советника(в отдельном окне)!
2. "Что касается доступа к истории, то универсального решения тут нет. Терминал заранее не может предсказать желание потребителя, т.е. хочет ли эксперт получить только одну дату или хочет запросить всю доступную историю"
Не нужно предугадывать желания потребителя. Нужно просто "сказать" в каком состоянии данные по символу И ВСЁ!.
Тогда пользователь ТОЧНО будет знать какие действия ему нужно совершать далее.
3."Но если программист не будет зацикливаться на требованиях переписать терминал "лично под себя", то найдет решение в имеющемся функционале."
Я не говорил, а тем более не требовал что-то делать "под себя", и решение, конечно всегда найдётся в имеющимся функционале.
4. "Если решения нет совсем, то вот только тогда встает вопрос расширения функционала."
Не надо расширять функционал, можно просто ввести незначительные изменения для удобства и быстроты использования.
5. "Описывайте конкретную проблему с конкретным кодом, без обобщений. Иначе получается, что непонятый функционал одной единственной функции раздувается до "все не так" и "все неудобно" "
Хорошо, я подготовлюсь для "расширенного" разъяснения проблемы с конкретным кодом.
Только, к сожалению, на справочник "опираться" нельзя...
Как всегда позиция пользователя - я центр вселенной и мир вращается вокруг меня. Нужно использовать тот функционал, который есть. Тем более не один раз было показано, как получить данные.
barabashkakvn: Как всегда позиция пользователя - я центр вселенной и мир вращается вокруг меня. Нужно использовать тот функционал, который есть. Тем более не один раз было показано, как получить данные.
barabashkakvn: Как всегда позиция пользователя - я центр вселенной и мир вращается вокруг меня. Нужно использовать тот функционал, который есть. Тем более не один раз было показано, как получить данные.
А вы считаете наоборот. Центр вселенной - это разработчики и мир вращается вокруг них ? Так что ли ?
Тогда на один вопрос ответе, терминал этот для кого разрабатывается ? Разработчики сами для себя его делают или для пользователя ?
Если сами для себя то вопросов нет... все ок.
А вот если для пользователя, то к их мнению нужно как минимум прислушиваться...
Описывайте конкретную проблему с конкретным кодом, без обобщений. Иначе получается, что непонятый функционал одной единственной функции раздувается до "все не так" и "все неудобно".
Описываю:
Реальный счёт ФОРТС брокера.
Проблема - Не получаю данные таймсерии.
1. На картинках видно, что данные в терминале есть.
2015.03.3106:39:16.826 Ind_test (BR-4.15,M1) OnInit: Получение баров для символа BR-5.15...
2015.03.3106:39:16.827 Ind_test (BR-4.15,M1) GetBars: Символ НЕ синхронизирован. Загрузка данных с сервера...
2015.03.3106:39:16.848 Ind_test (BR-4.15,M1) LoadServerData: Символ синхронизирован.
2015.03.3106:39:16.848 Ind_test (BR-4.15,M1) GetLocalData: Первая дата в терминале есть.
2015.03.3106:39:16.848 Ind_test (BR-4.15,M1) GetLocalData: Не удалось построить таймсерию!
2015.03.3106:39:16.848 Ind_test (BR-4.15,M1) OnCalculate: Получение баров для символа BR-5.15...
2015.03.3106:39:16.848 Ind_test (BR-4.15,M1) GetBars: Символ синхронизирован.
2015.03.3106:39:16.848 Ind_test (BR-4.15,M1) GetBars: Серия синхронизирована.
2015.03.3106:39:16.848 Ind_test (BR-4.15,M1) OnCalculate: Не получены бары по символу - BR-5.152015.03.3106:39:49.379 Ind_test (ED-6.15,M1) OnInit: Получение баров для символа ED-9.15...
2015.03.3106:39:49.379 Ind_test (ED-6.15,M1) GetBars: Символ НЕ синхронизирован. Загрузка данных с сервера...
2015.03.3106:39:49.399 Ind_test (ED-6.15,M1) LoadServerData: Символ синхронизирован.
2015.03.3106:39:49.399 Ind_test (ED-6.15,M1) GetLocalData: Первая дата в терминале есть.
2015.03.3106:39:49.399 Ind_test (ED-6.15,M1) GetLocalData: Не удалось построить таймсерию!
2015.03.3106:39:49.399 Ind_test (ED-6.15,M1) OnCalculate: Получение баров для символа ED-9.15...
2015.03.3106:39:49.399 Ind_test (ED-6.15,M1) GetBars: Символ синхронизирован.
2015.03.3106:39:49.399 Ind_test (ED-6.15,M1) GetBars: Серия синхронизирована.
2015.03.3106:39:49.399 Ind_test (ED-6.15,M1) OnCalculate: Не получены бары по символу - ED-9.152015.03.3106:39:55.555 Ind_test (Eu-6.15,M1) OnInit: Получение баров для символа Eu-9.15...
2015.03.3106:39:55.555 Ind_test (Eu-6.15,M1) GetBars: Символ НЕ синхронизирован. Загрузка данных с сервера...
2015.03.3106:39:55.567 Ind_test (Eu-6.15,M1) LoadServerData: Символ синхронизирован.
2015.03.3106:39:55.567 Ind_test (Eu-6.15,M1) GetLocalData: Первая дата в терминале есть.
2015.03.3106:39:55.567 Ind_test (Eu-6.15,M1) GetLocalData: Не удалось построить таймсерию!
2015.03.3106:39:55.567 Ind_test (Eu-6.15,M1) OnCalculate: Получение баров для символа Eu-9.15...
2015.03.3106:39:55.567 Ind_test (Eu-6.15,M1) GetBars: Символ синхронизирован.
2015.03.3106:39:55.567 Ind_test (Eu-6.15,M1) GetBars: Серия синхронизирована.
2015.03.3106:39:55.567 Ind_test (Eu-6.15,M1) OnCalculate: Не получены бары по символу - Eu-9.152015.03.3106:40:01.683 Ind_test (GAZR-6.15,M1) OnInit: Получение баров для символа GAZR-9.15...
2015.03.3106:40:01.683 Ind_test (GAZR-6.15,M1) GetBars: Символ НЕ синхронизирован. Загрузка данных с сервера...
2015.03.3106:40:01.694 Ind_test (GAZR-6.15,M1) LoadServerData: Символ синхронизирован.
2015.03.3106:40:01.694 Ind_test (GAZR-6.15,M1) GetLocalData: Первая дата в терминале есть.
2015.03.3106:40:01.694 Ind_test (GAZR-6.15,M1) GetLocalData: Не удалось построить таймсерию!
2015.03.3106:40:01.694 Ind_test (GAZR-6.15,M1) OnCalculate: Получение баров для символа GAZR-9.15...
2015.03.3106:40:01.694 Ind_test (GAZR-6.15,M1) GetBars: Символ синхронизирован.
2015.03.3106:40:01.694 Ind_test (GAZR-6.15,M1) GetBars: Серия синхронизирована.
2015.03.3106:40:01.694 Ind_test (GAZR-6.15,M1) OnCalculate: Не получены бары по символу - GAZR-9.15
2015.03.3111:00:35.638 tmp6 (GAZR-6.15,M1) GetBars: Символ синхронизирован.
2015.03.3111:00:35.638 tmp6 (GAZR-6.15,M1) GetBars: Серия синхронизирована.
2015.03.3111:00:35.638 tmp6 (GAZR-6.15,M1) OnCalculate: Не получены бары по символу - GAZR-9.15
2. При наличии данных в ТЕРМИНАЛЕ (см. рис. все бары после 16 марта), мы вынуждены идти на сервер, это нормально?
Неудобство и долгое получение информации (для меня) - очевидно.
2015.03.3111:00:35.611 tmp6 (GAZR-6.15,M1) OnInit: Получение баров для символа GAZR-9.15...
2015.03.3111:00:35.611 tmp6 (GAZR-6.15,M1) GetBars: Символ НЕ синхронизирован. Загрузка данных с сервера...
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Блевать, Эдвард, блЕвать =)
Это я понял, но скажите, почему нельзя было сделать так, как я описал выше?
На скорость обработки информации это никак бы не повлияло:
Если была какая-либо информация по инструменту - заносим дату первого её появления и храним в памяти - 8 байт!
Можно даже не хранить, а когда делаешь SymbolSelect(), то заносить в память.
При обращении функцией SeriesInfoInteger ( SERIES_TERMINAL_FIRSTDATE ) получаем:
А -1 - нет никаких данных
Б. 0 - дпнные есть но не готовы
В. Дата первой информации
Тогда бы всё было ясно и прозрачно.
-1 - Идём на сервер
0 - Ждём следующей итерации, чтобы проверить и (или) построить таймсерию
> 0 Строим таймсерию
Из вашей справки я понял, что ВЫ почти так и сделали, оказывается нет.
Видимо один программист начинал писать, а кто-то другой закончил
Ваша реализация хороша для ФОРЕКС, но очень неудобна для ФОРТС.
На ФОРТС котировки могут долго не приходить, а таймсерия выгружается из паияти
и приходится весь процесс получения данных повторять снова, причём с заходом на сервер!
Для работы с данными множества символов используйте экспертов, все будет удобно и просто. Индикаторы в среде МТ5 в первую очередь рассчитаны на быстрый расчет по данным своей таймсерии и отображение результатов расчета на чарте. В процессе развития платформы они получили множество функций доступных экспертам, но базовые архитектурные ограничения остались. И нет никаких оснований полностью стирать отличие индикаторов от экспертов. Еще раз напоминаю, что самое существенное отличие заключается в наличии у экспертов собственного потока обработки. Расчет индикаторов происходит в служебном потоке, и этот поток выполняет множество других функций. Именно поэтому даже общий с экспертами функционал имеет разную реализацию.
Что касается доступа к истории, то универсального решения тут нет. Терминал заранее не может предсказать желание потребителя, т.е. хочет ли эксперт получить только одну дату или хочет запросить всю доступную историю. В терминале сделан выбор в пользу быстрого доступа к таймфрейму, т.е. по запросу пользователя делается попытка закэшировать актуальное (синхронизированное с сервером) состояние истории в полном объеме. Делается ставка на повторный активный доступ. Да, есть класс приложений где этот подход не удобен. Но если программист не будет зацикливаться на требованиях переписать терминал "лично под себя", то найдет решение в имеющемся функционале. Если решения нет совсем, то вот только тогда встает вопрос расширения функционала.
Описывайте конкретную проблему с конкретным кодом, без обобщений. Иначе получается, что непонятый функционал одной единственной функции раздувается до "все не так" и "все неудобно".
Для работы с данными множества символов используйте экспертов, все будет удобно и просто. Индикаторы в среде МТ5 в первую очередь рассчитаны на быстрый расчет по данным своей таймсерии и отображение результатов расчета на чарте. В процессе развития платформы они получили множество функций доступных экспертам, но базовые архитектурные ограничения остались. И нет никаких оснований полностью стирать отличие индикаторов от экспертов. Еще раз напоминаю, что самое существенное отличие заключается в наличии у экспертов собственного потока обработки. Расчет индикаторов происходит в служебном потоке, и этот поток выполняет множество других функций. Именно поэтому даже общий с экспертами функционал имеет разную реализацию.
Что касается доступа к истории, то универсального решения тут нет. Терминал заранее не может предсказать желание потребителя, т.е. хочет ли эксперт получить только одну дату или хочет запросить всю доступную историю. В терминале сделан выбор в пользу быстрого доступа к таймфрейму, т.е. по запросу пользователя делается попытка закэшировать актуальное (синхронизированное с сервером) состояние истории в полном объеме. Делается ставка на повторный активный доступ. Да, есть класс приложений где этот подход не удобен. Но если программист не будет зацикливаться на требованиях переписать терминал "лично под себя", то найдет решение в имеющемся функционале. Если решения нет совсем, то вот только тогда встает вопрос расширения функционала.
Описывайте конкретную проблему с конкретным кодом, без обобщений. Иначе получается, что непонятый функционал одной единственной функции раздувается до "все не так" и "все неудобно".
Добрый день, Антон!
Давайте "разберём" Ваш ответ:
1. "Для работы с данными множества символов используйте экспертов, все будет удобно и просто."
Мне нужна история (close) по 3-м символам с отображением на чарте.
Из советника есть другой способ получения истории по close?
И нужно "городить огород", чтобы нарисовать результаты из советника(в отдельном окне)!
2. "Что касается доступа к истории, то универсального решения тут нет. Терминал заранее не может предсказать желание потребителя, т.е. хочет ли эксперт получить только одну дату или хочет запросить всю доступную историю"
Не нужно предугадывать желания потребителя. Нужно просто "сказать" в каком состоянии данные по символу И ВСЁ!.
Тогда пользователь ТОЧНО будет знать какие действия ему нужно совершать далее.
3."Но если программист не будет зацикливаться на требованиях переписать терминал "лично под себя", то найдет решение в имеющемся функционале."
Я не говорил, а тем более не требовал что-то делать "под себя", и решение, конечно всегда найдётся в имеющимся функционале.
4. "Если решения нет совсем, то вот только тогда встает вопрос расширения функционала."
Не надо расширять функционал, можно просто ввести незначительные изменения для удобства и быстроты использования.
5. "Описывайте конкретную проблему с конкретным кодом, без обобщений. Иначе получается, что непонятый функционал одной единственной функции раздувается до "все не так" и "все неудобно" "
Хорошо, я подготовлюсь для "расширенного" разъяснения проблемы с конкретным кодом.
Только, к сожалению, на справочник "опираться" нельзя...
Спасибо, что ответили.
Как всегда позиция пользователя - я центр вселенной и мир вращается вокруг меня. Нужно использовать тот функционал, который есть. Тем более не один раз было показано, как получить данные.
Как всегда позиция пользователя - я центр вселенной и мир вращается вокруг меня. Нужно использовать тот функционал, который есть. Тем более не один раз было показано, как получить данные.
А вы считаете наоборот. Центр вселенной - это разработчики и мир вращается вокруг них ? Так что ли ?
Тогда на один вопрос ответе, терминал этот для кого разрабатывается ? Разработчики сами для себя его делают или для пользователя ?
Если сами для себя то вопросов нет... все ок.
А вот если для пользователя, то к их мнению нужно как минимум прислушиваться...
........
Описывайте конкретную проблему с конкретным кодом, без обобщений. Иначе получается, что непонятый функционал одной единственной функции раздувается до "все не так" и "все неудобно".
Описываю:
Реальный счёт ФОРТС брокера.
Проблема - Не получаю данные таймсерии.
1. На картинках видно, что данные в терминале есть.
2. Вот код:
3. А вот исход:
Как воспроизвести?
Терминал подключен к открытию, история по всем символам удалена с диска перед запуском
Лог индикатора с момента старта
Как видите менее чем через секунду с момента старта данные по символу стали доступны индикатору.
Как воспроизвести?
Терминал подключен к открытию, история по всем символам удалена с диска перед запуском
Лог индикатора с момента старта
Как видите менее чем через секунду с момента старта данные по символу стали доступны индикатору.
Добрый день!
Т.е СЕКУНДА, при электронной торговле - это не время?
1. То есть, при синхронизированном символе и синхронизированной таймсерии, мы не можем получить
бары (сразу) - это нормально?
(Для меня) - это ошибка.
2. При наличии данных в ТЕРМИНАЛЕ (см. рис. все бары после 16 марта), мы вынуждены идти на сервер, это нормально?
Неудобство и долгое получение информации (для меня) - очевидно.
Добрый день!
Т.е СЕКУНДА, при электронной торговле - это не время?