Делаем краудсорсовый проект по Canvas - страница 37

[Roman]

Алексей Барбашин:

Исходя из вышесказанного можно понять что элемент структуры является конкретным элементом управления диалога, он содержит свои собственные свойства и может содержать вложенные элементы управления. Набор свойств такого универсального элемента управления ограничивается только фантазией разработчика.

Конечно можно и не подниматься до структуры, а описывать свойства элементов управления в многомерном массиве, но это не рентабильно изначально так как нужно четко помнить в каком индексе хранится какое-то свойство. Да и массив не может содержать разнородные типы данных. Получается что описывать элемент управления при процедурном программировании возможно только через структуры. То есть элемент структуры  - это конкретный элемент управления, то есть конкретный объект диалога со своими свойствами.

В стандартной библиотеке, в Include есть папка Generic, в котором есть класс CHashMap реализующий интерфейс по типу ключ-значение.
Один объект может иметь набор значений любого типа. Хоть и дерево map имеет временную сложность выполнения, работает довольно быстро.
Может даже и подойдёт для описания свойств, надо пробовать в общем. 
Или другой тип класса использовать из данной библиотеки, который более подойдёт под задачу.

[Alexandr Andreev]

Прочитал еще раз, т.е. вы предлагаете, хранить масив равный масиву пикселей, для того чтобы в этом масиве хранить информацию (в вашем случае "номер какой функции" надо использовать для обработки). ?

[Roman]

Maxim Kuznetsov:

потом будет обратная фигнь - привязать интерфейс в график. Например сделать кнопку которая строго привязана к метке времени и цене.

вот отдельный GUI пишется влёт - со всеми таблицами, вкладками, менюшками и свистюшками. На C# или даже бейсике. А внутрь чарта - это существенная проблема для внешних приложений.

А зачем потом привязывать интерфейс к графику?
Ведь можно напрямую получать любые данные, те же метки времени и цену, из соответствующих функций.

[Реter Konow]

Alexandr Andreev:

Прочитал еще раз, т.е. вы предлагаете, хранить масив равный масиву пикселей, для того чтобы в этом масиве хранить информацию (в вашем случае "номер какой функции" надо использовать для обработки). ?

Если вы меня спрашиваете, то я ничего такого не предлагал. Я вообще ничего не предлагал.)) Просто немного описал свои взгляды. Можно не соглашаться.

[Алексей Барбашин]

Реter Konow:

В принципе, можно обобщить типы. Я пришел к выводу, что ничего страшного не случится, если подавляющее большинство свойств объектов будут иметь тип int. Все остальные (double практически отсутствует в свойствах граф.объектов) сокращенные типы я отмел ради упрощения. "Перерасход" памяти настолько ничтожный, что думать о нем нет смысла. Конечно, ради пущего профессионализма на такое кощунство пойтить никак нельзя))) Но, сейчас 21-й век и костер мне не грозит.)) 

Имена объектов я сделал номерами, и всунул в общий ряд свойств объектов. 

Единственное, где мне понадобился иной тип данных - это параметры элементов управления. Там я создал второе ядро, которое хранит свойства параметров, а сами значения в типе string, которое я легко привожу к чему угодно (точнее, к тому, что прописано в свойствах параметра).

ЗЫ. Под "параметром элемента управления" подразумевается УПРАВЛЯЕМЫЙ ЭЛЕМЕНТОМ ПАРАМЕТР.

Получается что глобальный массив, который содержит в себе все элементы управления и все их свойства, имеет размерность в глубину равную сумме всех различных свойств элементов управления. То есть даже если какие-то свойства элементу не нужны эти ячейки все равно будут в этом массиве, так как массив все же всегда равномерен.

Но удивление вызывает все же однотипность самого массива. В этом плане использование структуры является более чем оправданным, так как в этом случае каждое из свойств можно описать своим типом, в том числе и union.

Использование структур реально упрощает хранения свойств, не нужно себя ограничивать одним типом или отказываться от чего-либо. Не нужно заниматься преобразованиями из стринга в другие типы данных... Структура изначально снимает все эти ограничения.

Кроме самих свойств и координат в этом глобальном массиве нужно так же хранить и систему подчиненности элементов. Если на нашем рисунке изменился объект Caption, то подлежат перерисовке и кнопки, так как они располагаются на поле заголовка. То есть если изменился какой-нибудь "средний" элемент управления, то необходимо перерисовать все что находится на нем. Петр, как вы храните структуру зависимости объектов? 

[Реter Konow]

Алексей Барбашин:

Получается что глобальный массив, который содержит в себе все элементы управления и все их свойства, имеет размерность в глубину равную сумме всех различных свойств элементов управления. То есть даже если какие-то свойства элементу не нужны эти ячейки все равно будут в этом массиве, так как массив все же всегда равномерен.

Но удивление вызывает все же однотипность самого массива. В этом плане использование структуры является более чем оправданным, так как в этом случае каждое из свойств можно описать своим типом, в том числе и union.

Использование структур реально упрощает хранения свойств, не нужно себя ограничивать одним типом или отказываться от чего-либо. Не нужно заниматься преобразованиями из стринга в другие типы данных... Структура изначально снимает все эти ограничения.

Ядро - матрица. В ней умещаются все свойства обьектов. 

Вы можете выбрать свой метод. Но, за годы занятия gui, я пришел к выводу, что ни один иной способ не даст аналогичного по мощи роста функциональности развивающийся системы. Максимальные простота и эффективность и есть совершенство.

[Реter Konow]

Алексей Барбашин:

...Петр, как вы храните структуру зависимости объектов? 

Если имеете ввиду координатные зависимости, то тоже в ядре.

У меня есть специальный обработчик координатных зависимостей обьектов. Работает с любыми типами зависимостей. 

[Maxim Kuznetsov]

Roman:

А зачем потом привязывать интерфейс к графику?
Ведь можно напрямую получать любые данные, те же метки времени и цену, из соответствующих функций.

к тому что интерфейс приложения (то чем оперирует пользователь) не ограничивается единственным окном.

мы же про трейдинг ?

ну вот и размещение интерактивных элементов на чарте (и их привязки) внешними средствами почти не разрешимы.А это чуть-ли не основное и главное.

повторюсь: внешние диалоги/формы рисуются легко. А внутри чарта элементы без специфики терминала и конкретного чарта - почти никак.

[Roman]

Реter Konow:
Ядро - матрица. В ней умещаются все свойства обьектов. 

Вы можете выбрать свой метод. Но, за годы занятия gui, я пришел к выводу, что ни один иной способ не даст аналогичного по мощи роста функциональности развивающийся системы. Максимальные простота и эффективность и есть совершенство.

Матрица, это вложенность циклов, а вложенные циклы это время. Имхо без сарказма, просто логически рассуждаю.
 

[Алексей Барбашин]

Петр, получается следующее: ядро состоит из глобальной матрицы свойств элементов, глобальной матрицы значений элементов, глобальной матрицы зависимостей, глобальной матрицы картинок...

Если необходимо добавить еще какое-то свойство тогда увеличивается размерность матриц.

Доступы к свойствам выполняются строго по индексам, так как у ячеек нет имен. 

У структуры хотя бы к именам полей можно обращаться.

Петр, ты... гигант...

Я например вижу это так (упрощенно):

class CControl : public CObject

{

public:

        int ПозицияХ;

        int ПозицияY;

        int Длина;

        int Ширина;

        color ЦветОсновы;

        color ЦветБордюра;

        int ТолщинаБордюра;

}

Де-факто "класс" является конкретной строкой в Вашем глобальном массиве, только  более "человеческим" лицом. Классы предназначены для создания собственных объектов данных, с набором понятных свойств, к которым можно обращаться не по индексу, а по имени. Класс - это всего лишь универсальный конструктор типов.

Так вот создаем базовый контролл, который содержит самые общие свойства, которые имеются практически у любого элемента управления.

На его основе можно создавать специализированные объекты:

class CButton : public CControl 

{

public:

        string Заголовок;

        int Image[];

}

То есть каждый последующий тип элемента управления просто дополняет нужными свойствами базовый тип.

А поскольку, как ранее я написал, основные свойства хранятся в базовом контролле, то и обход "попадания" курсора в элемент управления производится при проверке одного типа данных: CControl. Найдя нужный объект программа тут же имеет доступ ко свойствам этого объекта, так как точка программы уже находится в самом объекте, точно так же как в твоем цикле программа находится на нужной строке массива.