Мой подход. Ядро - Движок. - страница 145
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я предполагаю, что каждый поток на движок и с движка должен иметь какой-то признак потока, разновидность магического числа, и признак потока, который работает с тестером (он неизменно-уникальный). Движок реагирует на текущий выставленный поток и советники, индикаторы реагируют на свой признак(Псевдомагчисло) инфопотока.Пойдет?
В тестере сейчас все прекрасно работает, с другого окна советником в тестере управляю. Режим тренажера.
Сейчас сообщения между советником и движком не привязаны к конкретному маджику или имени советника. То есть, если движок записывает информацию в ресурс, ее прочтет любой советник, настроенный на связь. Для того, чтобы разделить потоки общения, нужно чтобы каждый советник определял специальную метку в заголовке сообщения. И далее, либо читал и выполнял инструкции, либо игнорировал. Отдельная метка должна быть для советников в тестере.
Но тут мы приходим к необходимости универсального GUI для движка, через который можно было бы настраивать и переключать связь. Также, получать информацию о советниках.
Значит, нужно менять концепцию советников. Точнее, апгрейдить ее.
Вот тут загвоздка.
Должен быть либо кастомный GUI на каждый советник, либо общий GUI на все советники. Если общий, то он должен быть инвариантным. Заранее продуманным. Каждый советник (даже не имеющий GUI), должен иметь внутренние рычаги, которые он будет предоставлять движку.
Есть над чем подумать...
Но тут мы приходим к необходимости универсального GUI для движка, через который можно было бы настраивать и переключать связь. Также, получать информацию о советниках.
Просто должна в движке необходимая и достаточная постоянно оформленная и сконфигурированная административная часть, которая занимается администрированием управления и самая разнообразная кастомная часть, построенная по проекту заказчика.
Просто должна в движке необходимая и достаточная постоянно оформленная и сконфигурированная административная часть, которая занимается администрированием управления и самая разнообразная кастомная часть, построенная по проекту заказчика.
Вот эта административная часть и непонятна. Какой она должна быть?
Если движок работает с один советником, - это одно. А если с несколькими разными, другое.
Пока чувствуется нехватка концептуальной базы...
Вот эта административная часть и непонятна. Какой она должна быть?
Если движок работает с один советником, - это одно. А если с несколькими разными, другое.
Пока чувствуется нехватка концептуальной базы...
Допустим что-нибудь такое.
А в советнике или индикаторе в стартовых настройках Такое же поле "Объект 1" и т.п.
Допустим что-нибудь такое.
А в советнике или индикаторе в стартовых настройках Такое же поле "Объект 1" и т.п.
Интересно. То есть, этими кнопками переключать связь? Но, в таком случае, все советники должны быть копиями одного советника, запущенного на разных парах.
А если советники разные?
Допустим что-нибудь такое.
А в советнике или индикаторе в стартовых настройках Такое же поле "Объект 1" и т.п.
Реализую сначала это. С одним советником на разных парах. А потом, придумаю как быть в случае с разными советниками.
Кстати, вот неплохая демонстрация работы с конструктором. Динамично, без слов, и под музыку. :)
CREATING VISUAL STUDIO
https://www.mql5.com/ru/blogs/post/712102
Кстати, вот неплохая демонстрация работы с конструктором. Динамично, без слов, и под музыку. :)
CREATING VISUAL STUDIO
Оригинально.
Допустим что-нибудь такое.
А в советнике или индикаторе в стартовых настройках Такое же поле "Объект 1" и т.п.
Это отмечены как бы подключенные к управлению. А конкретно управляется же один какой-то. Значит где-то тумблер переключения с крупной индикацией.
Это отмечены как бы подключенные к управлению. А конкретно управляется же один какой-то. Значит где-то тумблер переключения с крупной индикацией.
У каждого советника своя копия ядра параметров. Его можно временно отключить от общего GUI и подключить к движку другой советник. Важно, чтобы это были копии одного эксперта.
Но, здесь возникают сложности, которые я и сам в полном объеме еще не представляю.
В теори, вопрос звучит так:
Зачем на каждый график копии советника, закидывать движок с GUI, если можно сделать один движок с общим GUI, и подключать его к копиям советника?
На практике, возникают технические сложности.
Копия советника может записывать новые значения в свою копию ядра параметров. Если связи с движком у одной из копий не будет, то ядро параметров будет менятся только на стороне копии. Значит, при переподключении, нужно будет передать все ядро параметров копии в движок, и тот перерисует все элементы во всех окнах, где требуется. В принципе, это возможно.
Или переделать само ядро параметров, сделав его ресурсом. В таком случае, движок сразу получит все изменения и только перерисует элементы. Это неплохая идея.
Но, что это нам дает?
Возможно, мы уменьшаем нагрузку процессора, освобождаем потоки. Если у нас запущено 10 копий советника на 10-ти парах, и мы закидываем на каждую движок с GUI, то суммарная нагрузка на процессор может быть слишком большой. Ведь каждый GUI требует перерисовки элементов, а это грузит процессор. НО, по факту, мы можем видеть только один конкретных GUI одной копии. Остальные скрыты.
Поэтому, наверное, это правильный путь. Сделать общий движок.