Галерея UI написанных на MQL - страница 75
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нам пока тоже. С чего-то придётся всё-таки начать. Разбегитесь и прыгайте.
Как СТАЛКЕР2, будем вместе доделывать.
Все векторные, полностью масштабируемые и настраиваемые для любого дисплея.
Все визуальные отображения работают асинхронно внутри основного класса, который обрабатывает и распределяет все события MQL по объектам в зависимости от настроек подписки и приоритетов событий.
Он также предоставляет API для доступа ко всем данным и управления торговлей с помощью обоих индикаторов, написанных на MQL (специальные шаблоны) и C#.
>400 классов, <>200 000 строк кода, 9 лет непрерывной разработки, MT4 и MT5 - идентичный код за счет использования условной компиляции и обратной совместимости базовых классов. Основная разработка только на MQL5.
Никаких оригинальных библиотек или классов.
Фактически, весь код на 99,99% написан на MQL, только взаимодействие с конвейерами и сравнение строк выполняются с использованием C#/DLL.
На скриншоте показана торговля CFD, но с отображением объема базовых фьючерсов. Поэтому также есть реальная книга заказов и профиль объема.
Текущий этап разработки VE:
С нетерпением ждем следующего обновления разработки.
Звучит потрясающе, Питер. Думаю, когда вы будете использовать VE для самостоятельной сборки, это даст вам ценные сведения о том, как работает ваш дизайн пользовательского интерфейса.
С нетерпением ждем следующего обновления разработки.
UI по-прежнему 100% чистый MQL.
Все векторное, полностью масштабируемое и настраиваемое под любой дисплей.
Все визуальные дисплеи работают асинхронно в рамках основного класса, который обрабатывает и распределяет все события MQL по объектам, в зависимости от их настроек подписки и на основе приоритетов событий.
Я надеюсь, что я не краду очень интересную тему и простите меня Питер, если я это сделаю, это не будет дискуссией, просто надеюсь на короткий ответ для теоретического интереса - вы имеете в виду, что у вас есть своего рода статический класс, который знает (отслеживает все указатели объектов) все объекты класса, инстанцированные в системе, и каждый объект имеет доступ к подписке на необходимые события на этом статическом классе управления, и этот статический класс управления синглтон просто доставляет события всем объектам? Если да, то считаете ли вы это правильным с точки зрения ООП или, может быть, это приемлемое событийно-ориентированное программирование? Поскольку вы написали об этом, я предполагаю, что вы захотите принять вопросы об этом, и если да, то, пожалуйста, давайте держать его как можно короче, чтобы не захватить эту тему, хотя это связано.
Я надеюсь, что я не украсть очень интересный поток и простите меня Питер, если я делаю, это не будет обсуждение просто надеюсь на короткий ответ для теоретического интереса - вы имеете в виду, что у вас есть своего рода статический класс, который знает (отслеживает все указатели объектов) все объекты класса инстанс в системе и каждый объект имеет доступ к подписаться на необходимые события на этот статический класс управления и этот статический класс управления синглтон просто доставляет события для всех объектов? Если да, то считаете ли вы это правильным с точки зрения ООП или, может быть, это приемлемое событийно-ориентированное программирование? Поскольку вы написали об этом, я предполагаю, что вы захотите принять вопросы об этом, и если да, то, пожалуйста, давайте держать его как можно короче, чтобы не захватить эту тему, хотя это связано.
Да, именно так.
Краткое описание:
Ядро получает все события MetaTrader, и любой объект может подписаться на него. Поэтому класс CObject тоже пришлось переделать/изменить, чтобы у любого объекта была функция "public: virtual void OnEACycle(CCycleParams * cpm)". Таким циклом может быть чарт-событие, init, deinit и т.д. У каждого объекта также может быть "public: virtual void OnEATick()". Приятным побочным эффектом является то, что таким образом вы получаете дополнительную возможность, поскольку вы можете подписаться на конец любого цикла, независимо от того, какой он. Это очень удобно для закрытия файла или завершения любой другой работы, просто в конце любого цикла.
Более того, каждый объект CObject может иметь дочерние объекты и подписчиков. Это означает, что объект может инициировать собственные события, например, нажатие на что-либо или что-то подобное. Тогда вы просто выполняете object.SubEvent(STH_CLICKED, params). Таким образом, сам объект не заботится о том, кому нужна эта информация, она просто распространяется среди подписчиков, они получают OnSubEvent(int msg, CSubEventParams * sep) и могут делать с ней все, что захотят.
В целом, этот способ более близок к тому способу кодирования, который мы знаем из C#, где вы также просто используете .Invoke() для запуска событий и не заботитесь о том, кто их получит.
На самом деле реализовать это не так уж и сложно, но, конечно, в конечном итоге все упирается в детали, поскольку это ядро/база для каждого отдельного советника или индикатора в будущем, который должен работать в любом сценарии.