Обсуждение статьи "Графические интерфейсы X: Выделение текста в многострочном поле ввода (build 13)"
Круто! Как обстоят дела с вставкой из буфера?
Я пока не обращался к разработчикам в сервисдеске с такой просьбой.
Наверное, нужно не только вставка из буфера, но также и отправка в буфер, чтобы можно было переносить текст между своими полями ввода, если возникла такая необходимость.
Здесь скорее всего нужна возможность обработки системных событий, которые вызваны нажатием комбинаций клавиш Ctrl + X (вырезать), Ctrl + C (копировать) и Ctrl + V (вставить).
Это будет любопытно.)
Покажете ли Вы в следующей статье новые рисованные элементы? Это будет очень любопытно.)
1. Да. Все элементы в итоге будут нарисованными. В рамках второго этапа развития: 1 элемент=1 объект (холст для рисования).
2. Да. Также как во всех элементах, которые уже нарисованы, использовался этот класс CCanvas. В нём уже есть готовые методы для рисования простых графических фигур. Хороший класс, которого если бы не было, то пришлось бы реализовывать самому. В тех элементах библиотеки, которые уже нарисованы, используются методы для попиксельного рисования и линиями, вывод текста, а также таких фигур, как прямоугольник, прямоугольник с заливкой.
...
С ООП-подходом всё намного проще, чем Вы описали. Изменения в уже описанной до этого схеме библиотеки минимальные. В итоге всё будет даже ещё удобнее и намного лучше, чем сейчас.
Вот именно этот рецепт развития системы без ее внутреннего перерождения мне совершенно незнаком. Это просто как грааль, - хочется верить что он есть, но это маловероятно...
Нарисовать элемент конечно не очень сложно. Из прямоугольников рисуется практически все (кроме градиента), но должна быть создана другая событийная модель. Функция OnChartEvent() уже не обеспечит фиксацию событий клика на рисованную деталь элемента. Также не поможет Zorder для определения приоритета. Еще давно я говорил Вам о создании карты обьектов, и перечеслял ее преимущества, но тогда Вы отказались от этого решения, а теперь, без него никуда.
Несомненно, что у рисованных элементов больше свойств, а взаимодействие с ними значительно более сложно. В этой технологии, система должна быть более целостной, а механизмы более универсальными. Например должна быть общая память для всех элементов интерфейса, содержащая значения всех их свойств. Это более эффективное решение, чем создавать множество отдельных массивов и переменных в разных структурах и классах. Всякие условности ООП (обьекты ссылки для доступа к переменным других классов из которых нужно получить значение какого то свойства какого то обьекта например) будут только тормозить и усложнять работу, а не упрощать ее. Еще у ООП есть один недостаток, из за которого я не жалею, что не имею преимущества использовать чужие классы как Вы. Разработчик который использует в своей разработке блоки созданные другими людьми, хуже знает свою разработку чем тот, кто создавал все сам, и вдобавок он более ограничен в возможности совершенствования в своей разработки не только потому, что хуже ее знает, но и потому, что переделывать чужие блоки он не будет, так как это не предусматривается "профессиональным стилем" разработки.
Все вышесказанное только мое мнение и я закончил его изложение.
С интересом посмотрю на дальнейшее развитие библиотеки.
Нарисовать элемент конечно не очень сложно. Из прямоугольников рисуется практически все (кроме градиента), но должна быть создана другая событийная модель. Функция OnChartEvent() уже не обеспечит фиксацию событий клика на рисованную деталь элемента. Также не поможет Zorder для определения приоритета. Еще давно я говорил Вам о создании карты обьектов, и перечеслял ее преимущества, но тогда Вы отказались от этого решения, а теперь, без него никуда.
Ошибаетесь, как всегда. Вот примеры, где уже даже в текущей модели, описанных Вами проблем у меня не возникает (см. GIF-анимации ниже). Таблица нарисованная и взаимодействие с ней одно из самых сложных из всех существующих элементов, если не сказать, что самое сложное. К тому же, это ещё не окончательная версия. Возможно уже в следующей статье для этой таблицы будет завершающая кода.
//---
Покажите, пожалуйста, как всё то же самое реализовано у Вас.
//---
... Несомненно, что у рисованных элементов больше свойств, а взаимодействие с ними значительно более сложно. В этой технологии, система должна быть более целостной, а механизмы более универсальными. Например должна быть общая память для всех элементов интерфейса, содержащая значения всех их свойств. Это более эффективное решение, чем создавать множество отдельных массивов и переменных в разных структурах и классах.
Мне намного проще взаимодействовать с рисованными элементами. Постепенно всё станет по максимуму универсальным. Вообще-то от статьи к статье в этой серии этот процесс должен быть заметен, если конечно читать внимательно, а не просто картинки смотреть. Вы можете делать общую память, а можно просто обеспечить лёгкий доступ из одного класса к свойствам каждого элемента, как это сделал я. Нельзя категорично утверждать, что должно быть так, а не иначе. Никто никому ничего не должен. В своих разработках можете делать так, как это Вам удобно. Предпочитаю иметь своё мнение на тот или иной счёт. Как показывает мне моя личная практика и жизненный опыт, многое из того, что говорят другие - ошибочно. При этом я и себя не исключаю из этого числа. Но не боюсь ошибаться и если ошибаюсь, то просто ищу способ, как исправить ошибку.
... Всякие условности ООП (обьекты ссылки для доступа к переменным других классов из которых нужно получить значение какого то свойства какого то обьекта например) будут только тормозить и усложнять работу, а не упрощать ее.
В Вашем случае - да, в моём - нет. )
Реter Konow:
Еще у ООП есть один недостаток, из за которого я не жалею, что не имею преимущества использовать чужие классы как Вы. Разработчик который использует в своей разработке блоки созданные другими людьми, хуже знает свою разработку чем тот, кто создавал все сам, и вдобавок он более ограничен в возможности совершенствования в своей разработки не только потому, что хуже ее знает, но и потому, что переделывать чужие блоки он не будет, так как это не предусматривается "профессиональным стилем" разработки.
В таком случае начинайте с нуля и в одиночку. Напишите свою ОС, затем торговый терминал с языком MQL, а уже потом начинайте разрабатывать свою библиотеку для создания графических интерфейсов. После того, как всё это сделаете, можете гордо стучать себя пяткой в грудь. )))
//---
P.S. А для меня задача стояла:
- Попрактиковаться в программировании.
- Написать для себя библиотеку для создания графических интерфейсов с качеством, которое бы меня удовлетворяло.
- Поделиться этой разработкой с MQL-сообществом.
- Хотя бы частично компенсировать трудозатраты на разработку. Спасибо MQ за поддержку проекта.
Думаю, что получилось очень даже неплохо. По крайней мере, результат нравится не только мне. :)
Анатолий, я изложил свое мнение, и у меня нет желания ввязываться с Вами в очередной ожесточенный спор.
Мои таблицы не закончены, но продемонстрированный Вами пример у меня работает также. Таблица интерактивна, в ячейках картинки, чекбоксы, и даже вып.список. столбцы тоже меняют ширину. Конечно, пока не все идеально работает... Внешний вид немного другой. Прибавление колонок и столбцов еще не реализовано. Показывать здесь не буду, а то опять забанят за пиар.
Все о чем я говорю, - это опыт который я получил в процессе тяжелейшего труда, и то что я им делюсь, не должно восприниматся враждебно. В конце концов, кто еще здесь с Вами сможет на равных обсуждать все эти вопросы?
Удачи.
Анатолий, я изложил свое мнение, и у меня нет желания ввязываться с Вами в очередной ожесточенный спор.
Хорошо, не буду Вас отвлекать. )
Мои таблицы не закончены, но продемонстрированный Вами пример у меня работает также. Таблица интерактивна, в ячейках картинки, чекбоксы, и даже вып.список. столбцы тоже меняют ширину. Конечно, пока не все идеально работает... Внешний вид немного другой. Прибавление колонок и столбцов еще не реализовано. Показывать здесь не буду, а то опять забанят за пиар.
У Вас есть замечательная возможность читать статьи на эту тему и даже использовать решения выложенные в исходных кодах легко и просто адаптируя их под свою схему.
Результаты Вы можете публиковать в своём блоге. Я слежу за Вашими публикациями. ;)
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Графические интерфейсы X: Выделение текста в многострочном поле ввода (build 13):
В этой статье будет реализована возможность выделения текста с помощью различных клавишных комбинаций и удаление выделенного текста, по образцу того, как это сделано в любом другом текстовом редакторе. Кроме этого, продолжим оптимизировать код и подготовим классы для перехода к завершающему процессу второго этапа развития библиотеки, когда все элементы управления будут нарисованными на отдельных картинках (холстах для рисования).
Метод CTextBox::DeleteSelectedText() вызывается не только при нажатии клавиши Backspace, но также: (1) при вводе нового символа и (2) при нажатии клавиши Enter. В этих случаях текст сначала удаляется, а затем осуществляется действие, соответствующее нажатой клавише.
Вот как это выглядит в готовом приложении:
Рис. 7. Демонстрация удаления выделенного текста.
Автор: Anatoli Kazharski