Делаем краудсорсовый проект по Canvas - страница 39
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
...
Петер, Вы проделали огромную работу по созданию библиотеки GUI в вашем стиле. Но если Вы планируете это дело опубликовать, то все же стоит все переделать под другую технологию. Я готов Вам в этом помочь и шаг за шагом перевести всю мощь Вашей библиотеки в новое русло.
Алексей, допустим, я бы захотел попробывать. Как вы предлагаете это сделать? Работа неимоверная.
Петер, я скорее всего даже не представляю и малой части того объема работы. который Вы провели, и больше чем уверен что просто недооцениваю весь масштаб созданных объектов. НО!
Как всегда есть НО!
Любой проект, даже не обязательно в программировании. можно рассматривать как в общем плане, так и в частностях.
Для начала мы абстрагируемся от объектов, которые созданы. То есть мы не будем их представлять ни как матрицу, ни как структуры, ни как классы. Просто примем понятие ОБЪЕКТ (он же элемент управления, он же форма, он же интерфейс в целом и так далее). Вы попробуйте изложить взаимодействие объектов структурно. Когда мы вместе разберемся в устройстве того, что построено, то на основании этого попробуем выявлять закономерности. В принципе их не придется выявлять так как Вы их давно выявили и сделали для них унифицированную обработку, Вы просто поясните принцип действия и назначение. Далее мы будем просто подменять в Вашем проекте одни объекты другими. Это конечно будет на порядок сложнее чем написать с нуля. Но в нашем случае немного иная цель, так что по большому счету спешить некуда. А вот публикации по переводу матричного алгоритма в объектный - это пожалуй будет интересно не только начинающим. Я убежден что в процессе этой работы подключатся и другие участники, выскажут свои идеи или подскажут более удобную реализацию того или иного алгоритма.
Так или иначе сама идея прежде всего должна быть представлена блок-схемой алгоритма.
Я высказал свое предложение. Но можно поступить и иначе, все зависит от Вашего желания и взгляда на данный вопрос (совместной работы).
Петер, я скорее всего даже не представляю и малой части того объема работы. который Вы провели, и больше чем уверен что просто недооцениваю весь масштаб созданных объектов. НО!
Как всегда есть НО!
Любой проект, даже не обязательно в программировании. можно рассматривать как в общем плане, так и в частностях.
Для начала мы абстрагируемся от объектов, которые созданы. То есть мы не будем их представлять ни как матрицу, ни как структуры, ни как классы. Просто примем понятие ОБЪЕКТ (он же элемент управления, он же форма, он же интерфейс в целом и так далее). Вы попробуйте изложить взаимодействие объектов структурно. Когда мы вместе разберемся в устройстве того, что построено, то на основании этого попробуем выявлять закономерности. В принципе их не придется выявлять так как Вы их давно выявили и сделали для них унифицированную обработку, Вы просто поясните принцип действия и назначение. Далее мы будем просто подменять в Вашем проекте одни объекты другими. Это конечно будет на порядок сложнее чем написать с нуля. Но в нашем случае немного иная цель, так что по большому счету спешить некуда. А вот публикации по переводу матричного алгоритма в объектный - это пожалуй будет интересно не только начинающим. Я убежден что в процессе этой работы подключатся и другие участники, выскажут свои идеи или подскажут более удобную реализацию того или иного алгоритма.
Так или иначе сама идея прежде всего должна быть представлена блок-схемой алгоритма.
Я высказал свое предложение. Но можно поступить и иначе, все зависит от Вашего желания и взгляда на данный вопрос (совместной работы).
Хорошо. Сделаю что могу. Буду разьяснять решения и архитектуру. Но, мне неизвестно, будет ли в итоге успех.
Сейчас объекты упорядочены в ядре. Их нужно вынуть из него, и поместить в классы.
1. Наверное, я бы создал три базовых класса: "Rectangle_label", который вместит в себя все базовые свойства прямоугольных меток, "Icon", и "Text". Эти объекты входят в состав почти всех элементов управления.
2. Далее, создал бы группу классов-наследников. Их разделил бы по следующим критериям: а)элементы которые управляют параметром. б)элементы которые управляются параметром.
3. В классах описал бы специфические свойства каждого элемента.
Это только первые идеи. Возможно, ошибочные.
При такой схеме, наследование сразу получается множественным - классы элементов (наследники) должны включать в себя свойства сразу трех базовых классов.
Хорошо. Сделаю что могу. Буду разьяснять решения и архитектуру. Но, мне неизвестно, будет ли в итоге успех.
Сейчас объекты упорядочены в ядре. Их нужно вынуть из него, и поместить в классы.
1. Наверное, я бы создал три базовых класса: "Rectangle_label", который вместит в себя все базовые свойства прямоугольных меток, "Icon", и "Text". Эти объекты входят в состав почти всех элементов управления.
2. Далее, создал бы группу классов-наследников. Их разделил бы по следующим критериям: а)элементы которые управляют параметром. б)элементы которые управляются параметром.
3. В классах описал бы специфические свойства каждого элемента.
Это только первые идеи. Возможно, ошибочные.
При такой схеме, наследование сразу получается множественным - классы элементов (наследники) должны включать в себя свойства сразу трех базовых классов.
Ну вот пошло некоторое рассуждение.
"я бы создал три базовых класса: "Rectangle_label", который вместит в себя все базовые свойства прямоугольных меток, "Icon", и "Text"" - классически первый объект обзывают просто Rectangle либо Rect, второй обобщенно Image, ну а третий можно либо отдельными свойствами описать либо тоже сделать отдельным объектом. Для указания того, что созданный тип данных является классом в c++ и в mql принято перед названием типа указывать C, то есть CRectangle, CImage, CText. Но простые типы, которые просто содержат разнородные данные, удобнее создавать в виде структур.
Первично стоит рассмотреть все базовые свойства БОЛЬШИНСТВА элементов управления. В дальнейшем можно будет добавлять любые свойства, это не будет проблемой.
"а)элементы которые управляют параметром. б)элементы которые управляются параметром. " - тут требуется расшифровка. Я не понял что обозначают эти описания.
"будет ли в итоге успех" - лучше все же быть уверенным что успех будет. В противном случае лучше не начинать.Ну вот пошло некоторое рассуждение.
1. "я бы создал три базовых класса: "Rectangle_label", который вместит в себя все базовые свойства прямоугольных меток, "Icon", и "Text"" - классически первый объект обзывают просто Rectangle либо Rect, второй обобщенно Image, ну а третий можно либо отдельными свойствами описать лобо тоже сделать отбельным объектом. Для указания того, что созданный тип данных является классом в c++ и в mql принято перед названием типа указывать C, то есть CRectangle, CImage, CText
2. "а)элементы которые управляют параметром. б)элементы которые управляются параметром. " - тут требуется расшифровка. Я не понял что обозначают эти описания.
"будет ли в итоге успех" - лучше все же быть уверенным что успех будет. В противном случае лучше не начинать.1. Самый базовый класс - СGObject (базовый графический объект). Там должны быть свойства х,у, х_size, y_sixe и разные типы координатных привязок. Это общие свойства ВСЕХ объектов.
2. От него наследники - CRec, CImage, CText. В них специфические, присущие только им свойства.
3. Далее, классы платформ окон. Их несколько штук: Окно меню, Окно настроек, Диалоговое окно, Динамичное окно. Там набор специфических свойств.
3. Потом, - классы элементов. Их может быть до 50-ти штук. Деляться на категории: 1)по методу обработки параметра, 2)Декоративные.
Это самое начало. Мы ведь должны сделать язык разметки, а не библиотеку. Иначе - какой смысл?
ЗЫ. Большинство элементов упраления работают с параметром, который им предоставляют. Суть их предназначения - управлять некоторым пользовательским параметром. Но, каждый элемент делает это по своему.
ЗЫЫ. Забыл добавить - нужен базовый класс параметра с его свойствами. СParam например.
1. Самый базовый класс - СGObject (базовый графический объект). Там должны быть свойства х,у, х_size, y_sixe и разные типы координатных привязок. Это общие свойства ВСЕХ объектов.
2. От него наследники - CRec, CImage, CText. В них специфические, присущие только им свойства.
3. Далее, классы платформ окон. Их несколько штук: Окно меню, Окно настроек, Диалоговое окно, Динамичное окно. Там набор специфических свойств.
3. Потом, - классы элементов. Их может быть до 50-ти штук. Деляться на категории: 1)по методу обработки параметра, 2)Декоративные.
Это самое начало. Мы ведь должны сделать язык разметки, а не библиотеку. Иначе - какой смысл?
ЗЫ. Большинство элементов упраления работают с параметром, который им предоставляют. Суть их предназначения - управлять некоторым пользовательским параметром. Но, каждый элемент делает это по своему.
У меня небольшой взрыв мозга... )) Это все нужно нарисовать, иначе не переварить. )
У меня небольшой взрыв мозга... )) Это все нужно нарисовать, иначе не переварить. )
)) Ничего...
У базового класса параметра CParam есть несколько наследников. Суть в том, что есть общие свойства у управляемых параметров элементов, и есть специфические. Например: кнопка имеет тип управляемого параметра bool, а выпадающий список - тип "menu". То есть, кнопка переключает 1/0, а список - предлагает ограниченную выборку. Слайдер, например, имеет тип параметра "range" - то есть диапазон. Есть еще несколько типов и у всех есть уникальные свойства.
Поэтому, классы наследники от базового класса параметра тоже должны быть. Что то вроде "CBool", "CRange", "CMenu".
)) Ничего...
У базового класса параметра CParam есть несколько наследников. Суть в том, что есть общие свойства у управляемых параметров элементов, и есть специфические. Например: кнопка имеет тип управляемого параметра bool, а выпадающий список - тип "menu". То есть, кнопка переключает 1/0, а список - предлагает ограниченную выборку. Слайдер, например, имеет тип параметра "range" - то есть диапазон. Есть еще несколько типов и у всех есть уникальные свойства.
Поэтому, классы наследники от базового класса параметра тоже должны быть. Что то вроде "CBool", "CRange", "CMenu".
Погоди. Попробуем рассмотреть сейчас немного абстрактно.
Петер, с твоей точки зрения что общего между такими элементами управления как Кнопка, Текстовая метка, поле ввода, поле картинки ?
Погоди. Попробуем рассмотреть сейчас немного абстрактно.
петер, с твоей точки зрения что общего между такими элементами управления как Кнопка, Текстовая метка, поле ввода, поле картинки ?
1. Координаты, размеры.
2. Координатные зависимости, размерные зависимости.
3. Еще куча вещей в зависимости от общего количества свойств в управляющем функционале. У меня в ядре 270 свойств. Общих большинство. Но, у меня развитый функционал, который поддерживает множество возможностей. Поэтому, такое количество свойств. Мы должны начать с самых простых свойств.
1. Координаты.
2. Координатные зависимости.
3. Еще куча вещей в зависимости от общего количества свойств в управляющем функционале. У меня в ядре 270 свойств. Общих большинство. Но, у меня развитый функционал, который поддерживает множество возможностей. Поэтому, такое количество свойств. Мы должны начать с самых простых свойств.
Да, конечно с самых простых свойств. Из каких примитивных объектов может состоять та же Текстовая метка? Или из каких примитивных объектов может состоять в простом варианте Кнопка?