Обсуждение статьи "Графические интерфейсы I: Подготовка структуры библиотеки (Глава 1)" - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Отлично. Если можно, побольше картинок с примерами графических интерфейсов. Вообще тема очень нужная: давно нужно было начать документировать стандартную библиотеку.
Возможно я неправильно понял вопрос перед этим.
Под использованием классов из стандартной библиотеки я имел в виду только классы вот такого рода:
То есть, те классы, с помощью которых можно создать объекты-примитивы, получить и изменить их свойства.
Но (уточню) я не использую из стандартной библиотеки ту часть, которая предлагается для создания графических интерфейсов. Это полностью отдельный проект.
P.S. Картинок и примеров будет много (максимальная детализация).
Возможно я неправильно понял вопрос перед этим.
Под использованием классов из стандартной библиотеки я имел в виду только классы вот такого рода:
То есть, те классы, с помощью которых можно создать объекты-примитивы, получить и изменить их свойства.
Но (уточню) я не использую из стандартной библиотеки ту часть, которая предлагается для создания графических интерфейсов. Это полностью отдельный проект.
P.S. Картинок и примеров будет много (максимальная детализация).
А, теперь понятно.
А почему Вы решили не базировать свой проект на библиотеке графических интерфейсов от MQ? Может быть проще было бы расширить и углубить?
Кстати у меня есть собственная библиотека графических интерфейсов, было бы интересно сравнить концепции.
А, теперь понятно.
А почему Вы решили не базировать свой проект на библиотеке графических интерфейсов от MQ? Может быть проще было бы расширить и углубить?
Кстати у меня есть собственная библиотека графических интерфейсов, было бы интересно сравнить концепции.
Я об этом в самом начале этой статьи изложил свои мысли. Если кратко, то, чтобы всё было правильно (на мой взгляд), нужно было начать проект с нуля.
Думаю, что первые 14 статей этой серии уже позволят Вам полноценно произвести корректное сравнение концепций. Здесь очень много нюансов, без реализации которых нельзя было добиться высокого качества.
Интересный и полезный проект задумали! С нетерпением буду ждать публикации Ваших статей!
С Уважением...
День добрый!
У меня сложилось двоякое чувство при ознакомлении с созданной библиотекой. С одной стороны поражает глебина реализации и гибкость библиотеки. Труд проделан огромный, за что конечно можно высказать большое СПАСИБО!
С другой стороны реализация некоторых моментов вызывает недоумение, так как повышает трудоемкость создания новых форм.
Рассмотрим к примеру функции по перемещению формы по графику.
В функции нужно выполнять перечисление всех созданных объектов формы. Для чего? Ведь все созданные элементы помещаются в контейнер (массив) самой формы. Для чего в функции перечислять все создаваемые элементы? Почему нельзя просто обойти контейнер в цикле и выполнить изменение координат всех элементов?
То же самое касается и других методов. К примеру в функции Hide() все элементы скрываются путем перебора элементов формы в цикле, а в функции Delete() все элементы перечисляются дискретно. Непонятно.
Это приводит к тому, что при добавлении новых элементов на форму необходимо помнить все СТАНДАРТНЫЕ функции, в которых нужно указать каждый новый элемент. Это очень НЕ удобно. Все то же самое относится и к фокусу на элементе. Если элемент находится в фокусе, то его отображение должно изменяться согласно алгоритму ПРИ ЕГО СОЗДАНИИ, например для кнопок на основе картинок указываются картинки "BmpFileOn" и "BmpFileOff". Там же можно было задавать и другие свойства для фокуса: цвет рамки, цвет фона, цвет текста, размер текста и так далее. И в этом случае нет никакой необходимости прописывать его в функции определения фокуса, достаточно просто обойти массив элементов и установить их свойства согласно свойств "в фокусе"/"не в фокусе".
Сворачивание...
Изначально библиотека проработана таким образом, что сворачивание формы происходит под заголовок (вверх). При этом заголовок остается в том месте, где находится форма. Я пытаюсь реализовать стандартное поведение созданной формы, то есть когда при сворачивании окно сворачивается вниз и остается только заголовок (внизу) . Более того, пытаюсь реализовать два режима формы: "стандартное", "минимизированное", ну и конечно свернутое.
Уже на этапе создания своих кнопок столкнулся со всеми указанными проблемами. А разработка только началась....
Так же полагаю что универсальнее было бы создавать не один контейнер (массив) для хранения созданных элементов и операций над ними, а иерархию контейнеров. То есть для всей формы создается единый контейнер, который позволяет выполнять общие действия над формой: перемещение, удаление, скрытие и так далее. Этот контейнер должен включать в себя два других контейнера: контейнер элементов заголовка, контейнер элементов самой формы. Возможен и третий: контейнер подвала, если он есть. В свою очередь контейнер самой формы может содержать контейнеры блоков размещения элементов на форме. При такой реализации скажем сворачивание формы вниз должно привести к удалению элементов контейнера самой формы и перемещению элементов контейнера заголовка. При общих действиях выполнять операции над самими контейнерами. То есть если перемещается сама форма, то перемещается контейнер элементов всей формы (приложения).
Надеюсь автору будет понятна моя мысль. :)
Еще раз повторюсь: работа проведена огромная, полезная, познавательная. Но любой шаг в сторону от авторского представления начинает создавать сложности. Конечно полностью универсальных решений не бывает. Но некоторые общие стандартные функции быблиотеки можно было бы сделать действительно универсальными.
С уважением, Алексей.
...Надеюсь автору будет понятна моя мысль...
Мысль понятна. Спасибо.
Библиотека находится на стадии развития. Это ещё далеко не последняя версия и многие части в ней будут оптимизироваться и развиваться.
Последнюю на текущий момент (2016.11.20) версию можно скачать вот в этой статье: Графические интерфейсы X: Текстовое поле ввода, слайдер картинок и простые элементы управления (build 5)
Мысль понятна. Спасибо.
Библиотека находится на стадии развития. Это ещё далеко не последняя версия и многие части в ней будут оптимизироваться и развиваться.
Последнюю на текущий момент (2016.11.20) версию можно скачать вот в этой статье: Графические интерфейсы X: Текстовое поле ввода, слайдер картинок и простые элементы управления (build 5)
Я знаю что не последняя. :) Я скачал именно последнюю для мт4 и на ней пытаюсь строить интерфейс. Но я так понимаю что библиотека для мт5 дубет так же работать и под мт4, если там конечно не применялись специфические для мт5 механизмы.
Надеюсь те замечания и предложения, что я озвучил, найдут отражение в следующих версиях библиотеки и она станет еще более гибкой и универсальной, и в то же время более простой с точки зрения практического применения. При разработке библиотеки был применен "каскадный" механизм наследования классов, то же самое я предложил и для формирования элементов формы, то есть наследование контейнеров. При чем потомок может использовать свойства не только глобального характера (всей формы-приложения), но и свойства родителя: точки привязки, видимость, перемещение и так далее. :)
С большим нетерпением буду следить за выходом новых статей и за развитием библиотеки.
С уважением, Алексей.
Я знаю что не последняя. :) Я скачал именно последнюю для мт4 и на ней пытаюсь строить интерфейс. Но я так понимаю что библиотека для мт5 дубет так же работать и под мт4, если там конечно не применялись специфические для мт5 механизмы.
Версия для MT4 больше не будет развиваться с моей стороны. Только для MT5.
Надеюсь те замечания и предложения, что я озвучил, найдут отражение в следующих версиях библиотеки и она станет еще более гибкой и универсальной, и в то же время более простой с точки зрения практического применения.
Изначально сказать что-то сложно. Размышлять теоретически, как было бы лучше, можно долго. Всё будет ясно на реальных тестах.
Версия для MT4 больше не будет развиваться с моей стороны. Только для MT5.
Изначально сказать что-то сложно. Размышлять теоретически, как было бы лучше, можно долго. Всё будет ясно на реальных тестах.
Да, я уже читал о том, что для мт4 версия развиваться не будет - это не страшно.
Ну а то, что только тесты могут показать как лучше построить библиотеку - это бесспорно. Но с точки зрения ООП предложенный метод имеет наибольшие шансы практической реализации. :)