Обсуждение статьи "Язык MQL как средство разметки графического интерфейса MQL-программ (Часть 1)"
Еще раз внимательно перечитал статью и не нашел концепции языка разметки. Есть размышления по поводу реализаций на других языках и возможностей заимствовать какие то библиотеки, но концепцию автор еще не построил. Без нее, что либо заимствовать или модифицировать нет смысла.
Концепция должна быть описана простыми и ясными словами, без кодов, и объяснять суть технологии - что и как должно работать. А в статье сразу какие то коды, примеры и т.д... О чем они?
Глава: "Проектируем язык разметки" не содержит концепции языка разметки. Автор, обратите внимание, что о технологии языка разметки Вы ничего не написали, а углубились сразу в какие то детали, как, где и что можно заимствовать. Потом, Вы рассуждаете о некой иерархии контроллов (которой по факту не излагаете) и уходите в непривязанную ни к чему конкретику.
Нужно начинать с концепции создаваемой технологии, а ее пока нет.
Хорошая статья и правильные решения, приятно читать.
чтобы было совсем 5+,чутка не хватило - краткий обзор "а что плохого/хорошего есть в прочем мире" :-) Автор явно этим владеет и пишет не от пустого места ..
ожидание от следующих частей: что-то типа Geometry & Style Managers (это чтобы избавится от высчитывания координат и раздачи цветов), работа GUI в плане взаимодействия с основной логикой.
еще одна прокладка...
А сколько частей будет, 38 или 55?
А сколько частей будет, 38 или 55?
не каждому дано "Войну и мир" на форуме MQL написать в статьях
автор более чем цикле из 4-х статей не был ранее замечен )))
Материал статьи вроде бы и хорошо читается, но возникает некий дискомфорт, где то я не знаю от чего отталкиваться - за основу взят XAML ? - его, к сожалению, не изучал и не пользуюсь, как впрочем кроме WinForms и не использую других возможностей C#
В целом, интересно, посмотрим что дальше, единственное пожелание картинок чуть больше, по моему очень сухо выглядит материал если просто почитать
Профессионализм автора вселяет надежду, при условии, что осилит концепцию вместе с реализацией с начала и до конца. Первая статья намекает о намерениях - взять готовую библиотеку, модифицировать и превратить в язык разметки. Не верю в смысл подобного решения. Сама библиотека - ограниченная, а язык разметки от нее будет слабым. Без качественно нового уровня технологии и контроллов на канвасе - "овчинка" выделки не стоит, а если автор возьмется за рисованные элементы - нужно переделывать основы. Все это требует очень глубокого понимания технологии и массы времени. Судя по тому, как автор цепляется за названия переменных (коих будут тысячи), синтаксис, правила, - боюсь, не дотянет до завершения...
НО! Это только первая статья. Посмотрим...
не каждому дано "Войну и мир" на форуме MQL написать в статьях
автор более чем цикле из 4-х статей не был ранее замечен )))
Материал статьи вроде бы и хорошо читается, но возникает некий дискомфорт, где то я не знаю от чего отталкиваться - за основу взят XAML ? - его, к сожалению, не изучал и не пользуюсь, как впрочем кроме WinForms и не использую других возможностей C#
В целом, интересно, посмотрим что дальше, единственное пожелание картинок чуть больше, по моему очень сухо выглядит материал если просто почитать
А я пробовал изучать XAML, только с самого легонца, и не понял шутки юмора - зачем изучать еще один язык, да еще крайне узко специализированный, который, к тому же, не расширяет возможности, а сужает. Все равно когда-нибудь захочется "подкрутить" что-то при работе программы или сделать интерфейс более гибким, вот и придется изучать, как все делается прямым образом без прокладок. Выигрыш от языка разметки незначителен, а если учесть, что его еще изучать надо, то очень сомнителен. Или я не въехал в идеологию XAML'a.
А я пробовал изучать XAML, только с самого легонца, и не понял шутки юмора - зачем изучать еще один язык, да еще крайне узко специализированный, который, к тому же, не расширяет возможности, а сужает. Все равно когда-нибудь захочется "подкрутить" что-то при работе программы или сделать интерфейс более гибким, вот и придется изучать, как все делается прямым образом без прокладок. Выигрыш от языка разметки незначителен, а если учесть, что его еще изучать надо, то очень сомнителен. Или я не въехал в идеологию XAML'a.
подождем автора статьи, может даст направление поиска чем удобен XAML, может почитаю, хотя главное, по сути - что будет итогом статьи, насколько это будет удобно и функционально, на данном этапе меня СБ устраивает для графических примитивов - исходники есть и читаемы
ЗЫ: насчет новых языков, ну все относительно, хотел СБ использовать, чтоб пару графиков в .bmp сохранять... ан не разобрался за день, плюнул прогуглил, за 15 минут с Google Charts ознакомился и вместо .bmp генерирую себе .html - даже оффлайн можно графики просматривать, т.е. удобство использования это залог использования! ;)
А я пробовал изучать XAML, только с самого легонца, и не понял шутки юмора - зачем изучать еще один язык, да еще крайне узко специализированный, который, к тому же, не расширяет возможности, а сужает. Все равно когда-нибудь захочется "подкрутить" что-то при работе программы или сделать интерфейс более гибким, вот и придется изучать, как все делается прямым образом без прокладок. Выигрыш от языка разметки незначителен, а если учесть, что его еще изучать надо, то очень сомнителен. Или я не въехал в идеологию XAML'a.
Большая ценность XAML это то, что он упрощает разработку всяких диалоговых окон и прочей муры. В MFC том же не просто создать список,
отличающийся внешним видом от стандартного, надо постараться, а здесь это раз-два. Я с ним ковырялся, он мозговыворачивающий, но если
нужно делать интерфейсы, то вполне можно освоить. Да и учить его не надо, это же просто кусок шарпа. Он реально начинает экономить время, не
сразу, по мере освоения.
Народ, вы чего навалились на человека с первой статьи, когда не видно результата? Ни разу комментов тут не писал, но ваши заставили.
Я не профессиональный программист, а любитель. И многие статьи тут, даже неудачные, заставляют меня искать более лучшие пути решения, более глубоко изучать языки программирования. Разбираться, почему автор реализовал именно такой способ решения задачи. Что то применять в своих наработках. Любая статья заставляет меня увеличивать количество знаний в разы, чем если бы я просто читал книги и документацию.
Вот простой пример. По GUI тут уже есть ряд статей, но реализовано все, хоть и с помощью классов, но в процедурном стиле. Громоздко, неудобно. Нужно понимать весь код, от начала до конца. Это заставило меня посмотреть на другие языки, такие как С++, С#, где переопределяя виртуальный метод, например doubleclick можно реализовать задуманное, не влезая в дебри.
Стал изучать шаблоны проектирования, динамические структуры данных, так как в mql нет делегатов, пришлось понять, что это за блюдо и с чем его едят. Пришлось переписать все стандартные классы. Начал с начала, с CObject. Написал в итоге простую реализацию обработки событий OnTradeTransaction, OnChartEvent, OnTimer с помощью "настоящего" ООП. С разметкой XAML, я не знаком, когда пробовал изучать показалась очень нудной, но теперь буду вникать, чтобы понимать чего хочет донести автор, и была возможность какие то его идеи реализовать у себя.
Так что прежде чем резко критиковать любую статью, думайте что есть такие как я, которым нужен разный взгляд на один и тот же предмет.
Предложите, направьте, если есть более глубокие познания. Объединитесь в команду. Это будет более продуктивно, чем гадить
статью.
- www.mql5.com
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Язык MQL как средство разметки графического интерфейса MQL-программ. Часть 1:
В статье предлагается новая концепция для описания оконного интерфейса MQL-программ с помощью конструкций языка MQL. Специальные классы преобразуют наглядную MQL-разметку в элементы GUI, позволяют унифицированным образом управлять ими, настраивать свойства и обрабатывать события. Приведены примеры использования разметки для диалогов и элементов стандартной библиотеки.
Для чего ракладку отделяют от кода и описывают на специальном языке? Вот основные преимущества такого подхода.
Для среды MQL были предприняты немногочисленные попытки решить кое-какие из этих задач. В частности, визуальный конструктор диалогов представлен в статье Как проектировать и конструировать классы объектов, он работает на основе библиотеки MasterWindows. Но способы раскладки и перечень поддерживаемых типов элементов в нем сильно ограничены.
Более продвинутая система раскладки, но без визуального дизайнера предложена в статьях Применение контейнеров для компоновки графического интерфейса: класс CBox и класс CGrid. Она поддерживает все стандартные элементы управления и прочие, унаследованные от CWndObj или CWndContainer, однако по-прежнему оставляет на пользователе рутинное программирование по созданию и размещению компонентов.
Концептуально данный подход с контейнерами является очень технологичным (достаточно указать на его популярность практически по всех языках разметки), и потому мы примем его на вооружение. В одной из моих предыдущих статей (Применение OLAP в трейдинге (Часть 2): Визуализация результатов интерактивного анализа многомерных данных) была предложена модификация контейнеров CBox и CGrid, а также некоторых элементов управления для поддержки свойств "резиновости". Далее мы воспользуемся этими наработками и усовершенствуем их для решения задачи автоматического размещения элементов на примере объектов стандартной библиотеки.
Автор: Stanislav Korotky