Мой подход. Ядро - Движок. - страница 146
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Реter Konow:
...
Это неплохая идея.
Но, что это нам дает?
Возможно, мы уменьшаем нагрузку процессора, освобождаем потоки. Если у нас запущено 10 копий советника на 10-ти парах, и мы закидываем на каждую движок с GUI, то суммарная нагрузка на процессор может быть слишком большой. Ведь каждый GUI требует перерисовки элементов, а это грузит процессор. НО, по факту, мы можем видеть только один конкретных GUI одной копии. Остальные скрыты.
Поэтому, наверное, это правильный путь. Сделать общий движок.
В МТ5 графики можно откреплять. И тогда вам придётся придумывать заново концепцию.
У каждого советника своя копия ядра параметров. Его можно временно отключить от общего GUI и подключить к движку другой советник. Важно, чтобы это были копии одного эксперта.
Но, здесь возникают сложности, которые я и сам в полном объеме еще не представляю.
В теори, вопрос звучит так:
Зачем на каждый график копии советника, закидывать движок с GUI, если можно сделать один движок с общим GUI, и подключать его к копиям советника?
На практике, возникают технические сложности.
Копия советника может записывать новые значения в свою копию ядра параметров. Если связи с движком у одной из копий не будет, то ядро параметров будет менятся только на стороне копии. Значит, при переподключении, нужно будет передать все ядро параметров копии в движок, и тот перерисует все элементы во всех окнах, где требуется. В принципе, это возможно.
Или переделать само ядро параметров, сделав его ресурсом. В таком случае, движок сразу получит все изменения и только перерисует элементы. Это неплохая идея.
Но, что это нам дает?
Возможно, мы уменьшаем нагрузку процессора, освобождаем потоки. Если у нас запущено 10 копий советника на 10-ти парах, и мы закидываем на каждую движок с GUI, то суммарная нагрузка на процессор может быть слишком большой. Ведь каждый GUI требует перерисовки элементов, а это грузит процессор. НО, по факту, мы можем видеть только один конкретных GUI одной копии. Остальные скрыты.
Поэтому, наверное, это правильный путь. Сделать общий движок.
Копии советников пусть с частотой сообщают движку свой адрес. Короткую строку. Движок среагирует и "заговорит" с копией, у которой адрес совпадает с его текущим. И состоится стандартный обмен. Если в движке адрес меняется, то он начинает "обмениваться" с той копией которая выставляет совпадаюший адрес. Просто к стандартному обмену в "эфир" добавляется выставление советниками или индикаторами своего короткого адреса. Несколько байт. А функция "выслушивания движком адресов запускается при нажатии пользователем на ГУИ движка кнопки "Перенастроить". Может как-то так.
В МТ5 графики можно откреплять. И тогда вам придётся придумывать заново концепцию.
Я просто не в курсе. График открепляется чисто "территориально", становится свободен от координат главного окна терминала? А в потоках обмена с терминалом как был связан в полном объеме, так и будет?
Я просто не в курсе. График открепляется чисто "территориально", становится свободен от координат главного окна терминала? А в потоках обмена с терминалом как был связан в полном объеме, так и будет?
График открепляется, но сути это не меняет. Зря кошмарят.) Нет смысла плодить копии GUI на каждую копию советника. Я, во всяком случае, не вижу. А вот перемещать один GUI между графиками копий, было бы здорово.
Если будет график центра управления копиями советника, на котором будет расположен движок и главный GUI, будет удобно.
Нужно, чтобы GUI советника делался с расчетом, что у советника будет много копий, поставленных на разных инструментах.
ЗЫ. График остается в том же окне, только само окно можно "вынуть", из Терминала.
Копии советников пусть с частотой сообщают движку свой адрес. Короткую строку. Движок среагирует и "заговорит" с копией, у которой адрес совпадает с его текущим. И состоится стандартный обмен. Если в движке адрес меняется, то он начинает "обмениваться" с той копией которая выставляет совпадаюший адрес. Просто к стандартному обмену в "эфир" добавляется выставление советниками или индикаторами своего короткого адреса. Несколько байт. А функция "выслушивания движком адресов запускается при нажатии пользователем на ГУИ движка кнопки "Перенастроить". Может как-то так.
Суть вы видите правильно. Только в деталях не точно.
Само переключение "общения", не проблема. Но, при переключении, нужно переинициализировать весь GUI. Ведь в окошках и элементах разных копий, разные значения. То есть, нужно перерисовывать почти все.
Значения параметров каждой копии храняться в Ядре параметров. Это массив. И пока копия отключена от движка, изменения значений будут происходить только в копии Ядра параметров эксперта. Как только движок подключится, нужно все в него передать из этого ядра. Синхронизировать копии Ядра параметров в Движке и подключенном эксперте. Значит, нужно передать большой массив информации (Ядро параметров), и перерисовать окна. После этого, можно будет регулировать подключенного эксперта, а другие перейдут в независимый режим работы. Потом, подключение осуществится с ними, и произойдет тоже самое.
Примерно так. Но, возникает масса технических нюансов.
Петр. С периодом N мс советник получает нечто от движка, и после этого передает в движок свое подготовленное нечто. После этого советник ждет прихода тика или новую порцию переопроса-обмена. Правильно?
Почти правильно. Общение и ожидание тика, или других событий, происходят асинхронно.
График открепляется, но сути это не меняет. Зря кошмарят.)
...
ЗЫ. График остается в том же окне, только само окно можно "вынуть", из Терминала.
И по вашей концепции, что всё равно одномоментно виден лишь один текущий график, и можно обновлять только его, будет сломана - будет видно столько графиков, сколько их откреплено.
Конечно не кошмар, но и не гут - будет "жить" лишь один график из видимых, а остальные?
Это вы считаете нормально? Ну если да, то ещё раз убеждаюсь о несерьёзности в решении багов - если он и есть, то не исправить, а спрятать.
Почти правильно. Общение и ожидание тика, или других событий, происходят асинхронно.
А если так. Советники, каждый с частой какой-то (OnTimer), посылают в движок свою кодовую строку. Все кодовые строки разные. Движок внутри себя анализирует приходящие строки и "узнает" одну, допустим от советника номер 3, к примеру. В ответ этому советнику он посылает "сигнал" начать основную передачу. Пошла работа движка с этим советником.
Если человек нажимает кнопку Переключить, движок анализирует разрешенные советники, а они у него проиндексированны, под номерами. Сообщает текущему советнику перейти в состояние выставления адреса, как бы выключает его из потоковой работы, у себя выбирает кодовую строку с индексом на 1 больше и ждет прихода такой же кодовой строки от какого-либо советника. При совпадении адресов посылает этому советнику сигнал закончить выставлять адрес и начать обмен. Получать обмен будет единственный советник и серии копий, который не находится в режиме выставления адреса. Короче, что-то вроде.
Если движок получил какой-то адрес, то он делает тайм-аут запрета получения адресов. Что-бы адреса не накладывались.
А если так. Советники, каждый с частой какой-то (OnTimer), посылают в движок свою кодовую строку. Все кодовые строки разные. Движок внутри себя анализирует приходящие строки и "узнает" одну, допустим от советника номер 3, к примеру. В ответ этому советнику он посылает "сигнал" начать основную передачу. Пошла работа движка с этим советником.
Если человек нажимает кнопку Переключить, движок анализирует разрешенные советники, а они у него проиндексированны, под номерами. Сообщает текущему советнику перейти в состояние выставления адреса, как бы выключает его из потоковой работы, у себя выбирает кодовую строку с индексом на 1 больше и ждет прихода такой же кодовой строки от какого-либо советника. При совпадении адресов посылает этому советнику сигнал закончить выставлять адрес и начать обмен. Получать обмен будет единственный советник и серии копий, который не находится в режиме выставления адреса. Короче, что-то вроде.
Если движок получил какой-то адрес, то он делает тайм-аут запрета получения адресов. Что-бы адреса не накладывались.
Вот тут не совсем правильный подход. Поясню:
Каждая копия советника не прекращает записывать свои сообщения движку в свой, отдельный ресурс. Вместе с этим, каждая копия советника, инициализирует значения своих элеметов в своей копии Ядра параметров. То есть, даже в отключенном от движка состоянии, во всех копиях советника все должно происходить штатно.
Когда движок переключает соединения между копиями советников, он должен синхронизировать свое ядро параметров, с ядром подключаемого советника. После этого, перерисовать элементы в окнах, чтобы они отображали актуальную информацию.
Что касается общения с выбранным советником, то здесь все просто. Ресурс для приема сообщений от движка (как и ресурс сообщений для движка), у каждого совеника будет свой. То есть, Движок будет просто записывать свои сообщения в другой ресурс, и читать сообщения из другого ресурса. Того ресурса, который принадлежит подключенному советнику.