Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ядро - матрица. В ней умещаются все свойства обьектов.
Петр, а у Вас есть опыт и примеры написания GUI не только в текущем варианте?
Вы напрочь отрицаете другие парадигмы, но беретесь утверждать что Ваша модель наиболее удачна для реализации GUI. Данное утверждение весьма спорно.
сделайте индикатор, который корректирует углы наклона нарисованных прямых, их точки пересечения и пропорции эллипсов. При том что опорные точки выставлены в будущем
спустя два выходных и какой-нить чёртов день-индюшки..
PS/ такое чувство что люди рисующие интерфейсы к торговле не причастны вообще
сделайте индикатор, который корректирует углы наклона нарисованных прямых, их точки пересечения и пропорции эллипсов. При том что опорные точки выставлены в будущем
спустя два выходных и какой-нить чёртов день-индюшки..
PS/ такое чувство что люди рисующие интерфейсы к торговле не причастны вообще
Макс, осмелюсь утверждать что в половине случаев именно так. Трейдер совершенно не обязан быть программистом, а программист совершенно не обязан быть трейдером.
Осмелюсь предположить что Петер кроме как на mql больше ни на чем не программирует. Все современные версии языков требуют знания работы с классами: джава, котлин, шарп, питон, с++ и так далее. Даже в 1С есть подобие классов в виде фиксированных типов объектов. Но это так, отступление.
С моем точки зрения система сборки интерфейса должна выглядеть следующим образом:
То есть создание интерфейса должно быть декларативным. Я даже не представляю как любой другой программист будет добавлять описание свойств элемента управления обращаясь по индексам.....
Уверен что даже для среднего программиста это будет головоломно, не говоря уже про начинающего.
Осмелюсь предположить что Петер кроме как на mql больше ни на чем не программирует. Все современные версии языков требуют знания работы с классами: джава, котлин, шарп, питон, с++ и так далее. Даже в 1С есть подобие классов в виде фиксированных типов объектов. Но это так, отступление.
С моем точки зрения система сборки интерфейса должна выглядеть следующим образом:
То есть создание интерфейса должно быть декларативным. Я даже не представляю как любой другой программист будет добавлять описание свойств элемента у правления обращаясь по индексам.....
Уверен что даже для среднего программиста это будет головоломно, не говоря уже про начинающего.
Если элементов много и/или свойства зависят от индекса, то без проблем и наоборот сложно писать портянку, обращаясь к каждому отдельному.
Матрица, это вложенность циклов, а вложенные циклы это время. Имхо без сарказма, просто логически рассуждаю.
1. Петр, получается следующее: ядро состоит из глобальной матрицы свойств элементов, глобальной матрицы значений элементов, глобальной матрицы зависимостей, глобальной матрицы картинок...
2. Если необходимо добавить еще какое-то свойство тогда увеличивается размерность матриц.
3. Доступы к свойствам выполняются строго по индексам, так как у ячеек нет имен.
У структуры хотя бы к именам полей можно обращаться.
Петр, ты... гигант...
Я например вижу это так (упрощенно):
4. Де-факто "класс" является конкретной строкой в Вашем глобальном массиве, только более "человеческим" лицом. Классы предназначены для создания собственных объектов данных, с набором понятных свойств, к которым можно обращаться не по индексу, а по имени. Класс - это всего лишь универсальный конструктор типов.
Так вот создаем базовый контролл, который содержит самые общие свойства, которые имеются практически у любого элемента управления.
На его основе можно создавать специализированные объекты:
То есть каждый последующий тип элемента управления просто дополняет нужными свойствами базовый тип.
А поскольку, как ранее я написал, основные свойства хранятся в базовом контролле, то и обход "попадания" курсора в элемент управления производится при проверке одного типа данных: CControl. Найдя нужный объект программа тут же имеет доступ ко свойствам этого объекта, так как точка программы уже находится в самом объекте, точно так же как в твоем цикле программа находится на нужной строке массива.
1. Ядро - это одна глобальная матрица. Два измерения. Ядро строится спец. функцией, которая читает файл, где на языке разметки написано, какие окна и элементы нужно создать.
Нисколько не усложняется, в этом и есть прелесть и мощь классов. Каждый следующий наращивает свою функциональность, базируясь на функциональности исходного объекта. В итоге всю основную функциональность (фокус, клики, выход за пределы элемента, перетаскивание, прорисовка) - все это реализуется на основе именно базовых объектов. Дальнейшая разработка и модификация, разработка новых элементов управления - все это уже никак не затронет базовую функциональность так как она создана на уровне, говоря Вашим языком: "ядра" библиотеки. При этом у объектов будут именно те типы данных, которые необходимы для конкретного свойства.
"Ядро строится спец. функцией, которая читает файл, где на языке разметки написано, какие окна и элементы нужно создать." - это просто жесть. То есть у Вас есть матрица, которая хранит все свойства, и еще есть файл с разметкой, которая указывает как именно нужно читать матрицу со свойствами... "Индексы названы через дефайны" - каждый индекс жестко привязан к дефайну. Случайная вставка дополнительного поля приведет к сдвигу свойств с последствиями. "При увеличении количества свойств обьектов матрица растет в ширину" - это я и имел ввиду, говоря про размерность (виноват, не верно применил термин). Создавая свой объект данных в виде класса вы избегаете всех этих сложностей. А это реальные сложности, которые на деле не нужны. Умеем же мы создавать себе сложности чтобы потом их успешно преодолевать.
Да и классы не обязательно создавать иерархическими, да и вообще их не обязательно использовать. Но вот использовать структуры для того чтобы избавиться от лишних потоков данных - это целесообразно. ИМХО
Петер, Вы проделали огромную работу по созданию библиотеки GUI в вашем стиле. Но если Вы планируете это дело опубликовать, то все же стоит все переделать под другую технологию. Я готов Вам в этом помочь и шаг за шагом перевести всю мощь Вашей библиотеки в новое русло.
Нисколько не усложняется, в этом и есть прелесть и мощь классов. Каждый следующий наращивает свою функциональность, базируясь на функциональности исходного объекта. В итоге всю основную функциональность (фокус, клики, выход за пределы элемента, перетаскивание, прорисовка) - все это реализуется на основе именно базовых объектов. Дальнейшая разработка и модификация, разработка новых элементов управления - все это уже никак не затронет базовую функциональность так как она создана на уровне, говоря Вашим языком: "ядра" библиотеки. При этом у объектов будут именно те типы данных, которые необходимы для конкретного свойства.
"Ядро строится спец. функцией, которая читает файл, где на языке разметки написано, какие окна и элементы нужно создать." - это просто жесть. То есть у Вас есть матрица, которая хранит все свойства, и еще есть файл с разметкой, которая указывает как именно нужно читать матрицу со свойствами... Создавая свой объект данных в виде класса вы избегаете всех этих сложностей. А это реальные сложности, которые на деле не нужны. Умеем же мы создавать себе сложности чтобы потом их успешно преодолевать.
Да и классы не обязательно создавать иерархическими, да и вообще их не обязательно использовать. Но вот использовать структуры для того чтобы избавиться от лишних потоков данных - это целесообразно. ИМХО
Петер, Вы проделали огромную работу по созданию библиотеки GUI в вашем стиле. Но если Вы планируете это дело опубликовать, то все же стоит все переделать под другую технологию. Я готов Вам в этом помочь и шаг за шагом перевести всю мощь Вашей библиотеки в новое русло.
Знаете, я здесь столько спорил о реализации своих и чужих решений, что устал. )) Просто, реально утомило. Мое мышление больше приспособлено под матрицу, мышление других под классы... не стоит на этом ломать копья.
В Вашем случае это не упрощение, а реальное усложнение. ИМХО