Делаем краудсорсовый проект по Canvas - страница 34
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я понял смысл, приложение отдельно, GUI отдельно.
Но обработка выводимых данных в GUI, всё равно выполняется синхронно.
То есть к примеру приложение отсылает в GUI 10000 элементов, и GUI все эти элементы обрабатывает последовательно.
В этом и проблема. Необходимо в GUI параллелить обработку входящих элементов, и их вывод. Основание, текст, значок.
Тем более, что на одну ячейку выполняется три цикла.
Все верно. Но, в текущих условиях распараллелить обработку неудобно. Нужно подключать еще советники или сервисы. Получится громоздкая и разорванная реализация.(
Есть какой то способ, основанный на объектах-чартах. Не вникал в него, но он может помочь создать несколько потоков. Там что то с шаблонами связано...
Я понял смысл, приложение отдельно, GUI отдельно.
Но обработка выводимых данных в GUI, всё равно выполняется синхронно.
То есть к примеру приложение отсылает в GUI 10000 элементов, и GUI все эти элементы обрабатывает последовательно.
В этом и проблема. Необходимо в GUI параллелить обработку входящих элементов, и их вывод. Основание, текст, значок.
Тем более, что на одну ячейку выполняется три цикла.
Это вряд ли получится. Даже винда обрабатывает интерфейс в одном потоке. В противном случае не определится приоритет окон и элементов управления. Разделить на потоки можно только сам GUI и обработку различных данных. Де-факто даже изменение данных в элементах управления недопустимо из другого потока. Диалог всегда должен быть целостным поэтому любая прорисовка и реакция любого диалога происходит строго в одном потоке, то есть все происходит синхронно.
Любые операции в МТ выполняются строго синхронно и этого реально не изменить пока разработчики не добавят потоки в приложение.
Весьма удивительно что разработчики стараются расширять функционал МТ в плане работы с базами данных, с питоном, с шарпом... но все это предлагают выполнять все в том же одном потоке...
Просто удивительно.
Согласен, с удивлением.
Выход, только пилить dll с асинхронными функциями к своим приложениям.
Но такие приложения даже в кодобазу не разместить, по причине запрета dll.
Это вряд ли получится. Даже винда обрабатывает интерфейс в одном потоке. Противном случае не определится приоритет окон и элементов управления. Разделить на потоки можно только сам GUI и обработку различных данных. Де-факто даже изменение данных в элементах управления недопустимо из другого потока. Диалог всегда должен быть целостным поэтому любая прорисовка и реакция любого диалога происходит строго в одном потоке, то есть все происходит синхронно.
А мне кажется, что всё получится, просто необходимо заранее продумать приоритет обработки асинхронных данных.
То есть выстроить схему асинхронной обработки, с синхронной.
Согласен, с удивлением.
Выход, только пилить dll с асинхронными функциями к своим приложениям.
Но такие приложения даже в кодобазу не разместить, по причине запрета dll.
На самом деле, реальной необходимости распараллеливать обработку событий GUI пока нет. Если таблицы в 1000 ячеек работают даже на МТ4 относительно быстро, то скорости на остальные события хватит с лихвой. В моей практике нет торможения. Если требуется сверх-быстрая анимация - можно подключить OpenCL. МТ5 тянет обычный GUI на отлично. Никаких проблем. Просто показал, что нужно аккуратно относится к вопросам перерисовки канваса.
Если сам советник будет включать в себя тяжелые вычисления, то частоту вывода данных в GUI можно уменьшить. Сама перерисовка большого окна может достигать 100 мс, но обычно гораздо меньше. Так что, задержка в 100 мс на ГУИ может быть заметна только при ОЧЕНЬ тяжелых вычислениях советника.
Согласен, с удивлением.
Выход, только пилить dll с асинхронными функциями к своим приложениям.
Но такие приложения даже в кодобазу не разместить, по причине запрета dll.
на уровне DLL можно сделать очень много всего.
Вот всё для чего MT не предназначен и можно+нужно там делать :-)
проконтроллировать dll нельзя, поэтому в маркете этого нет. А в кодобазе кстати попадаются dll. Может это сейчас с какого-то перепуга запретили
PS кстати любопытный вопрос - DLL-ка может быть подписана ключом разработчика. Можно по идее разрешать такие DLL и в маркете и кодобейзе, но это даст привязку к инфраструктуре Microsoft. Кто-нить тут готов купить такую лицензию на Visual C ?Согласен, с удивлением.
Выход, только пилить dll с асинхронными функциями к своим приложениям.
Но такие приложения даже в кодобазу не разместить, по причине запрета dll.
Да, в этом то и есть основная проблема! Тот же маркет запрещает использование dll, вот и приходится изобретать велосипед. Ладно если кто-то считает что GUI не нужны, но любые сложные длительные вычисления в любом случае в одном потоке не проведешь, все будет висеть! Значит это нужно делать в dll.. которые запрещены в маркете...
И так далее. По этой причине и приходится все прорисовывать и решать методами mql.
По сути разделить GUI и логику на потоки конечно можно уже и сейчас. Вот ребята обсуждали уже вопрос параллельности https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
В итоге можно саму форму оставлять в главном потоке, как это делается в винде, а любые дополнительные вычисления переносить в "фоновое" выполнение. Так работает и виндовс и линукс и андроид.
на уровне DLL можно сделать очень много всего.
Вот всё для чего MT не предназначен и можно+нужно там делать :-)
проконтроллировать dll нельзя, поэтому в маркете этого нет. А в кодобазе кстати попадаются dll. Может это сейчас с какого-то перепуга запретили
PS кстати любопытный вопрос - DLL-ка может быть подписана ключом разработчика. Можно по идее разрешать такие DLL и в маркете и кодобейзе, но это даст привязку к инфраструктуре Microsoft. Кто-нить тут готов купить такую лицензию на Visual C ?Да, проконтролировать dll нельзя, но ведь те же виндовые библиотеки разрешить можно же было бы...
Да что далеко ходить: даже в составе стандартной библиотеки есть функции доступа к винАПИ! А смысл? Ведь все рано это нельзя положить в маркет....
Ладно, мы этими разговорами в очередной флуд свалились.
на уровне DLL можно сделать очень много всего.
Вот всё для чего MT не предназначен и можно+нужно там делать :-)
проконтроллировать dll нельзя, поэтому в маркете этого нет. А в кодобазе кстати попадаются dll. Может это сейчас с какого-то перепуга запретили
PS кстати любопытный вопрос - DLL-ка может быть подписана ключом разработчика. Можно по идее разрешать такие DLL и в маркете и кодобейзе, но это даст привязку к инфраструктуре Microsoft. Кто-нить тут готов купить такую лицензию на Visual C ?А зачем привязываться на инфраструктуру Microsoft ?
По моему подписать dll можно абсолютно любым ключом, главное чтобы этот ключ как то контролировался MQ.
Из этого следует, что эти ключи должны выдаваться MQ, и контролировать хеш суммы приложения.
А зачем привязываться на инфраструктуру Microsoft ?
По моему подписать dll можно абсолютно любым ключом, главное чтобы этот ключ как то контролировался MQ.
Из этого следует, что эти ключи должны выдаваться MQ, и контролировать хеш суммы приложения.
а потому-что в этом муравейнике микрософт-главный :-)
как вы думаете почему у людей слетают логины при обновлениях винды и активации продуктов на пиратской винде ?