Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Исходя из вышесказанного можно понять что элемент структуры является конкретным элементом управления диалога, он содержит свои собственные свойства и может содержать вложенные элементы управления. Набор свойств такого универсального элемента управления ограничивается только фантазией разработчика.
Конечно можно и не подниматься до структуры, а описывать свойства элементов управления в многомерном массиве, но это не рентабильно изначально так как нужно четко помнить в каком индексе хранится какое-то свойство. Да и массив не может содержать разнородные типы данных. Получается что описывать элемент управления при процедурном программировании возможно только через структуры. То есть элемент структуры - это конкретный элемент управления, то есть конкретный объект диалога со своими свойствами.
В стандартной библиотеке, в Include есть папка Generic, в котором есть класс CHashMap реализующий интерфейс по типу ключ-значение.
Один объект может иметь набор значений любого типа. Хоть и дерево map имеет временную сложность выполнения, работает довольно быстро.
Может даже и подойдёт для описания свойств, надо пробовать в общем.
Или другой тип класса использовать из данной библиотеки, который более подойдёт под задачу.
Прочитал еще раз, т.е. вы предлагаете, хранить масив равный масиву пикселей, для того чтобы в этом масиве хранить информацию (в вашем случае "номер какой функции" надо использовать для обработки). ?
потом будет обратная фигнь - привязать интерфейс в график. Например сделать кнопку которая строго привязана к метке времени и цене.
вот отдельный GUI пишется влёт - со всеми таблицами, вкладками, менюшками и свистюшками. На C# или даже бейсике. А внутрь чарта - это существенная проблема для внешних приложений.
А зачем потом привязывать интерфейс к графику?
Ведь можно напрямую получать любые данные, те же метки времени и цену, из соответствующих функций.
Прочитал еще раз, т.е. вы предлагаете, хранить масив равный масиву пикселей, для того чтобы в этом масиве хранить информацию (в вашем случае "номер какой функции" надо использовать для обработки). ?
Если вы меня спрашиваете, то я ничего такого не предлагал. Я вообще ничего не предлагал.)) Просто немного описал свои взгляды. Можно не соглашаться.
В принципе, можно обобщить типы. Я пришел к выводу, что ничего страшного не случится, если подавляющее большинство свойств объектов будут иметь тип int. Все остальные (double практически отсутствует в свойствах граф.объектов) сокращенные типы я отмел ради упрощения. "Перерасход" памяти настолько ничтожный, что думать о нем нет смысла. Конечно, ради пущего профессионализма на такое кощунство пойтить никак нельзя))) Но, сейчас 21-й век и костер мне не грозит.))
Имена объектов я сделал номерами, и всунул в общий ряд свойств объектов.
Единственное, где мне понадобился иной тип данных - это параметры элементов управления. Там я создал второе ядро, которое хранит свойства параметров, а сами значения в типе string, которое я легко привожу к чему угодно (точнее, к тому, что прописано в свойствах параметра).
ЗЫ. Под "параметром элемента управления" подразумевается УПРАВЛЯЕМЫЙ ЭЛЕМЕНТОМ ПАРАМЕТР.Получается что глобальный массив, который содержит в себе все элементы управления и все их свойства, имеет размерность в глубину равную сумме всех различных свойств элементов управления. То есть даже если какие-то свойства элементу не нужны эти ячейки все равно будут в этом массиве, так как массив все же всегда равномерен.
Но удивление вызывает все же однотипность самого массива. В этом плане использование структуры является более чем оправданным, так как в этом случае каждое из свойств можно описать своим типом, в том числе и union.
Использование структур реально упрощает хранения свойств, не нужно себя ограничивать одним типом или отказываться от чего-либо. Не нужно заниматься преобразованиями из стринга в другие типы данных... Структура изначально снимает все эти ограничения.
Кроме самих свойств и координат в этом глобальном массиве нужно так же хранить и систему подчиненности элементов. Если на нашем рисунке изменился объект Caption, то подлежат перерисовке и кнопки, так как они располагаются на поле заголовка. То есть если изменился какой-нибудь "средний" элемент управления, то необходимо перерисовать все что находится на нем. Петр, как вы храните структуру зависимости объектов?Получается что глобальный массив, который содержит в себе все элементы управления и все их свойства, имеет размерность в глубину равную сумме всех различных свойств элементов управления. То есть даже если какие-то свойства элементу не нужны эти ячейки все равно будут в этом массиве, так как массив все же всегда равномерен.
Но удивление вызывает все же однотипность самого массива. В этом плане использование структуры является более чем оправданным, так как в этом случае каждое из свойств можно описать своим типом, в том числе и union.
Использование структур реально упрощает хранения свойств, не нужно себя ограничивать одним типом или отказываться от чего-либо. Не нужно заниматься преобразованиями из стринга в другие типы данных... Структура изначально снимает все эти ограничения.
...Петр, как вы храните структуру зависимости объектов?
А зачем потом привязывать интерфейс к графику?
Ведь можно напрямую получать любые данные, те же метки времени и цену, из соответствующих функций.
к тому что интерфейс приложения (то чем оперирует пользователь) не ограничивается единственным окном.
мы же про трейдинг ?
ну вот и размещение интерактивных элементов на чарте (и их привязки) внешними средствами почти не разрешимы.А это чуть-ли не основное и главное.
повторюсь: внешние диалоги/формы рисуются легко. А внутри чарта элементы без специфики терминала и конкретного чарта - почти никак.
Ядро - матрица. В ней умещаются все свойства обьектов.
Матрица, это вложенность циклов, а вложенные циклы это время. Имхо без сарказма, просто логически рассуждаю.
Петр, получается следующее: ядро состоит из глобальной матрицы свойств элементов, глобальной матрицы значений элементов, глобальной матрицы зависимостей, глобальной матрицы картинок...
Если необходимо добавить еще какое-то свойство тогда увеличивается размерность матриц.
Доступы к свойствам выполняются строго по индексам, так как у ячеек нет имен.
У структуры хотя бы к именам полей можно обращаться.
Петр, ты... гигант...
Я например вижу это так (упрощенно):
Де-факто "класс" является конкретной строкой в Вашем глобальном массиве, только более "человеческим" лицом. Классы предназначены для создания собственных объектов данных, с набором понятных свойств, к которым можно обращаться не по индексу, а по имени. Класс - это всего лишь универсальный конструктор типов.
Так вот создаем базовый контролл, который содержит самые общие свойства, которые имеются практически у любого элемента управления.
На его основе можно создавать специализированные объекты:
То есть каждый последующий тип элемента управления просто дополняет нужными свойствами базовый тип.
А поскольку, как ранее я написал, основные свойства хранятся в базовом контролле, то и обход "попадания" курсора в элемент управления производится при проверке одного типа данных: CControl. Найдя нужный объект программа тут же имеет доступ ко свойствам этого объекта, так как точка программы уже находится в самом объекте, точно так же как в твоем цикле программа находится на нужной строке массива.