Делаем краудсорсовый проект по Canvas - страница 35
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
кстати, раз уж люди занимаются ранее давно пройденным:
это случайно взятый скриншот из yandex, GUI интерфейса клиент-сервер, да ещё и по сети. Не надо изобретать велосипед...
(секунда рекламы) Pi - реально круто. Там живёт честный вольфрам :-)
Да, в этом то и есть основная проблема! Тот же маркет запрещает использование dll, вот и приходится изобретать велосипед. Ладно если кто-то считает что GUI не нужны, но любые сложные длительные вычисления в любом случае в одном потоке не проведешь, все будет висеть! Значит это нужно делать в dll.. которые запрещены в маркете...
И так далее. По этой причине и приходится все прорисовывать и решать методами mql.
По сути разделить GUI и логику на потоки конечно можно уже и сейчас. Вот ребята обсуждали уже вопрос параллельности https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
В итоге можно саму форму оставлять в главном потоке, как это делается в винде, а любые дополнительные вычисления переносить в "фоновое" выполнение. Так работает и виндовс и линукс и андроид.
Да, видел я эту статью, которая в своём роде очередной костыль с кучей кода, в котором даже нет желания разбираться.
Когда всё намного быстрее и проще делается в dll.
Кстати и от mql Socket и WebRequest я отказался, по причине того, что когда mql сервер не доступен, по причине обрыва связи,
то блокируется выполнение функций сокета или вебреквеста, так что имейте это ввиду, если решите строить приложения на mql сокетах и вебреквестах.
кстати, раз уж люди занимаются ранее давно пройденным:
это случайно взятый скриншот из yandex, GUI интерфейса клиент-сервер, да ещё и по сети. Не надо изобретать велосипед...
(секунда рекламы) Pi - реально круто. Там живёт честный вольфрам :-)
кстати и Scratch на скриншоте - примерно то что хочет делать Конов, складываем алгоритм из кубиков.
а потому-что в этом муравейнике микрософт-главный :-)
как вы думаете почему у людей слетают логины при обновлениях винды и активации продуктов на пиратской винде ?
Да при чём тут Microsoft и ключи подписи dll? Которые только идентифицируют разработчика.
Ключи для подписи dll, могут выдавать MQ, тем кто прошёл полную идентификацию в маркете.
Этим ключом, разработчик подписывает свою dll для идентификации, кем была написана dll.
То есть ключ подписи dll, не как не затрагивает активацию продукта.
///
Ты можешь понять, что на МКЛ нет нормального GUI? Тот что есть - это 95-й год. Стыдно должно быть... А ты с призывами к стороннему ГУИ подумал как им в МТ пользоватся? Как подключить? Или медом не корми, дай банальность сказать?))
Ты можешь понять, что на МКЛ нет нормального GUI? Тот что есть - это 95-й год. Стыдно должно быть... А ты с призывами к стороннему ГУИ подумал как им в МТ пользоватся? Как подключить? Или медом не корми, дай банальность сказать?))
Peter, я Вам наверное открою глаза и скажу за Максима: Максим как никто другой знаком с данной темой и еще года полтора назад выкладывал на всеобщее обозрение свой вариант GUI, формируемый вроде как на основе разметки. Причем GUI строился во внешней среде, но имел полное взаимодействие с программой (индикатор, эксперт).
Максим, извини что за тебя ответил.
Хочу вернуться все же к теме. Выдернул рисунок из одной статьи про работу стандартной библиотеки:
Данный скрин в упрощенной форме показывает состав диалога.
В данной версии Border является основным элементом, он то и создает объект канваса на графике, а все подчиненные рисуют на нем. Вернее рисуют в зависимости от подчиненности.
Кнопка Close рисуется на Caption, в свою очередь Caption рисуется на Border, а вот он уже со всеми нарисованными элементами рисуется на канвасе.
Peter, я Вам наверное открою глаза и скажу за Максима: Максим как никто другой знаком с данной темой и еще года полтора назад выкладывал на всеобщее обозрение свой вариант GUI, формируемый вроде как на основе разметки. Причем GUI строился во внешней среде, но имел полное взаимодействие с программой (индикатор, эксперт).
Максим, извини что за тебя ответил.
Хочу вернуться все же к теме. Выдернул рисунок из одной статьи про работу стандартной библиотеки:
Данный скрин в упрощенной форме показывает состав диалога.
В данной версии Border является основным элементом, он то и создает объект канваса на графике, а все подчиненные рисуют на нем. Вернее рисуют в зависимости от подчиненности.
Кнопка Close рисуется на Caption, в свою очередь Caption рисуется на Border, а вот он уже со всеми нарисованными элементами рисуется на канвасе.
Я не знаю, что он выкладывал и чем занимался в вопросах GUI, но в моих ветках он не сделал ни одного технического предложения, ни одного решения и не вел никаких обсуждений по теме. Только пустой троллинг, указание на сторонние решения и призывы не изобретать велосипед.
Вернемся к теме.
На сколько я знаком со стандартной библиотекой (очень мало на самом деле), там элементы и окна состоят из МТ-объектов. То есть, в нашем контексте, - они не нарисованы на канвасе. Конечно, они нарисованы, но не на нашем канвасе, что не дает нам возможность управлять цветами пикселей, создавать градиенты поверхностей и многое другое.
В теории, можно взять структуру библиотеки, скопировать и сделать аналог на канвасе. В теории...
Проблема в том, что сам ССanvas - не удобен для создания GUI на нем. Почему? Потому что там система работы с канвасом приспособлена в основном для графических примитивов. То есть, по сути, ничего кроме примитивов этот класс не предоставляет. Архетиктуру ГУИ нужно строить самому. А в этом случае, класс необязателен. Удобнее обойтись своими решениями. Ведь нарисовать прямоугольную метку можно и без этого класса. Как и создать или загрузить канвас. Это очень просто. Поэтому, я предпочел свое решение.
Но, кому то без CCanvas никак. Поэтому, не настаиваю.
Я не знаю, что он выкладывал и чем занимался в вопросах GUI, но в моих ветках он не сделал ни одного технического предложения, ни одного решения и не вел никаких обсуждений по теме. Только пустой троллинг, указание на сторонние решения и призывы не изобретать велосипед.
Вернемся к теме.
На сколько я знаком со стандартной библиотекой (очень мало на самом деле), там элементы и окна состоят из МТ-объектов. То есть, в нашем контексте, - они не нарисованы на канвасе. Конечно, они нарисованы, но не на нашем канвасе, что не дает нам возможность управлять цветами пикселей, создавать градиенты поверхностей и многое другое.
В теории, можно взять структуру библиотеки, скопировать и сделать аналог на канвасе. В теории...
Проблема в том, что сам ССanvas - не удобен для создания GUI на нем. Почему? Потому что там система работы с канвасом приспособлена в основном для графических примитивов. То есть, по сути, ничего кроме примитивов этот класс не предоставляет. Архетиктуру ГУИ нужно строить самому. А в этом случае, класс необязателен. Удобнее обойтись своими решениями. Ведь нарисовать прямоугольную метку можно и без этого класса. Как и создать или загрузить канвас. Это очень просто. Поэтому, я предпочел свое решение.
Но, кому то без CCanvas никак. Поэтому, не настаиваю.
Стоп! Петр (верно?), давай для понимания друг друга примем некоторые условности. Условность 1: Канвасом мы будем называть не класс CCanvas, а просто холст для рисования часть экрана, или конкретно один ресурс. Класс CCanvas никакого отношения ко всему этому не имеет и мы вообще зацикливаться на нем не будем. Он всего лишь предоставляет функции для рисования на том самом холсте и все! По факту мы рисовать можем самыми различными методами.
Под словом "рисовать" будем понимать формирование массива пикселей, на основании которого и создается ресурс, который в последствии размещается на чарте.
Стоп! Петр (верно?), давай для понимания друг друга примем некоторые условности. Условность 1: Канвасом мы будем называть не класс CCanvas, а просто холст для рисования часть экрана, или конкретно один ресурс. Класс CCanvas никакого отношения ко всему этому не имеет и мы вообще зацикливаться на нем не будем. Он всего лишь предоставляет функции для рисования на том самом холсте и все! По факту мы рисовать можем самыми различными методами.
Под словом "рисовать" будем понимать формирование массива пикселей, на основании которого и создается ресурс, который в последствии размещается на чарте.
Все верно.
Peter, я Вам наверное открою глаза и скажу за Максима: Максим как никто другой знаком с данной темой и еще года полтора назад выкладывал на всеобщее обозрение свой вариант GUI, формируемый вроде как на основе разметки. Причем GUI строился во внешней среде, но имел полное взаимодействие с программой (индикатор, эксперт).
Максим, извини что за тебя ответил.
Хочу вернуться все же к теме. Выдернул рисунок из одной статьи про работу стандартной библиотеки:
Данный скрин в упрощенной форме показывает состав диалога.
В данной версии Border является основным элементом, он то и создает объект канваса на графике, а все подчиненные рисуют на нем. Вернее рисуют в зависимости от подчиненности.
Кнопка Close рисуется на Caption, в свою очередь Caption рисуется на Border, а вот он уже со всеми нарисованными элементами рисуется на канвасе.
немного конечно не так :-)
я выкладывал интерфейс к DLL Tcl (который Tool Common Language), у которого графика Tk , которые совместно используются как GUI в Python/Ruby/etc
не было целью получить GUI, это как-бы приятный побочный результат :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
на мой взгляд удобно, а главное кратко :-)
никого не агитирую - я tcl/tk знаю, использую, наработками поделился (см. sourceforge atcl)