Обсуждение статьи "Графические интерфейсы X: Расширенное управление списками и таблицами. Оптимизация кода (build 7)"
Опубликована статья Графические интерфейсы X: Расширенное управление списками и таблицами. Оптимизация кода (build 7):
Автор: Anatoli Kazharski
к чему обращаться чтобы сделать тоже самое со списком комбобоска, так не работает:
if(id==CHARTEVENT_CUSTOM+..){
m_combobox_sm.Clear();
m_combobox_sm.ItemsTotal(4);
m_combobox_sm.VisibleItemsTotal(4);
string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};
for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}
}
к чему обращаться чтобы сделать тоже самое со списком комбобоска, так не работает:
if(id==CHARTEVENT_CUSTOM+..){
m_combobox_sm.Clear();
m_combobox_sm.ItemsTotal(4);
m_combobox_sm.VisibleItemsTotal(4);
string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};
for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}
}
В классе CComboBox есть методы, которые возвращают указатели на список и полосу прокрутки. Получив указатели на эти элементы Вы сможете вызывать их методы.
CListView *GetListViewPointer(void) { return(::GetPointer(m_listview)); }
CScrollV *GetScrollVPointer(void) { return(m_listview.GetScrollVPointer()); }
1. Стиль зебра будет теперь устанавливаться по умолчанию для свех таблиц, или я неверно понял?
1. Стиль "Зебра" включаемый режим. По умолчанию отключен. Если нужен, то достаточно вызвать соответствующий метод, указав второй цвет. Вообще-то в статье об этом достаточно подробно рассказано.
2. Будет возможно.
3. Я подумаю об этом в рамках дальнейшей оптимизации кода.
1. Стиль "Зебра" включаемый режим. По умолчанию отключен. Если нужен, то достаточно вызвать соответствующий метод, указав второй цвет. Вообще-то в статье об этом достаточно подробно рассказано.
2. Будет возможно.
3. Я подумаю об этом в рамках дальнейшей оптимизации кода.
3. Честно говоря, несколько удивлен наличием в Вашей программе повторяющихся методов. Жаль, я не изучал более внимательно... Хоть Вы и считаете мой код "неоптимизированной грудой", но у меня не повторяется ни один механизм дважды. Похожих функций нет. Чего и Вам желаю. )
На текущий момент, когда элементы в своём большинстве собираются из нескольких графических объектов, то без общих виртуальных методов не обойтись. Под оптимизацией в этой части имел ввиду тот этап развития, когда все элементы будут рисоваться. Тогда, предположу, эти стандартные виртуальные методы можно свести в одно объявление и имплементацию в базовом классе элемента.
А Ваш код я вообще не хочу обсуждать здесь. Он ведь закрытый, поэтому держите его при себе. Моё мнение о том, что я у Вас видел, не изменилось.
1. На текущий момент, когда элементы в своём большинстве собираются из нескольких графических объектов, то без общих виртуальных методов не обойтись. Под оптимизацией в этой части имел ввиду тот этап развития, когда все элементы будут рисоваться. Тогда, предположу, эти стандартные виртуальные методы можно свести в одно объявление и имплементацию в базовом классе элемента.
2. А Ваш код я вообще не хочу обсуждать здесь. Он ведь закрытый, поэтому держите его при себе. Моё мнение о том, что я у Вас видел, не изменилось.
1. Возможно, когда Вы займетесь реализацией технологии "рисованных" элементов управления, Вам удасться избавиться от дублирования методов. Однако, как Вы сами заметили - Вы предпологаете, что это поможет. То есть, - возможно и нет... Мое мнение - эти вещи никак не связаны.
"Рисованный" элемент управления функционально не отличается от элемента построенного из нескольких объектов, однако, для его создания нужна совершенно иная технология. То есть, технология отличающаяся от той, по которой создаются элементы из множества объектов.
Интересно, что и рисованный элемент состоит из нескольких объектов, но эти объекты, - с одной стороны не являются МТ-объектами (а просто деталями рисунка), а с другой стороны - внутри программы детали рисунка такие же функциональные объекты со своими свойствами.
То есть кол-во объектов меньше не становится. Просто из МТ-объектов, детали элементов (да и сами элементы) становятся внутренними объектами программы. А программа, (в отличии от функции OnChartEvent()), их видит, определяет и работает с ними.
Технология очень сложная и требует очень высокой оптимизированности кода...
2. Не имея представления как работает весь механизм в целом, Вы поторопились составить свое мнение. Поменять Вы его не могли, так как до сих пор видели ничтожную часть кода. Ну а мне придется смириться с таким Вашим представлением. Увы.)
P.S Обсуждать это не будем. Я и не обижаюсь. :)
1. Возможно, когда Вы займетесь реализацией технологии "рисованных" элементов управления, Вам удасться избавиться от дублирования методов. Однако, как Вы сами заметили - Вы предпологаете, что это поможет. То есть, - возможно и нет... Мое мнение - эти вещи никак не связаны.
Предполагаю, так как пока не реализовал и не протестировал.
"Рисованный" элемент управления функционально не отличается от элемента построенного из нескольких объектов, однако, для его создания нужна совершенно иная технология. То есть, технология отличающаяся от той, по которой создаются элементы из множества объектов.
Интересно, что и рисованный элемент состоит из нескольких объектов, но эти объекты, - с одной стороны не являются МТ-объектами (а просто деталями рисунка), а с другой стороны - внутри программы детали рисунка такие же функциональные объекты со своими свойствами.
То есть кол-во объектов меньше не становится. Просто из МТ-объектов, детали элементов (да и сами элементы) становятся внутренними объектами программы. А программа, (в отличии от функции OnChartEvent()), их видит, определяет и работает с ними.
Вы пишите такие очевидные вещи, что даже обсуждать это с Вами неинтересно. Я вижу это немного иначе. Своё мнение выскажу в одной из следующих статей второго этапа развития библиотеки.
Предполагаю, так как пока не реализовал и не протестировал.
Вы пишите такие очевидные вещи, что даже обсуждать это с Вами неинтересно. Я вижу это немного иначе. Своё мнение выскажу в одной из следующих статей второго этапа развития библиотеки.
Ну, не знаю почему для Вас эти вещи очевидны. Разве Вы это уже реализовали?
Технология о которой мы говорили не описана ни в одной статье по MQL. Или я ошибаюсь и Вы можете дать ссылку?
Главное - придти к этой технологии посредством косметической оптимизации невозможно, - нужна "замена фундамента".
Замена фундамента - тяжелейший процесс. Обычно все рушиться, - схемы, взаимосвязи, механизмы... ВСЕ. Потом все восстанавливается по новой.
В общем, - врагу не пожелаешь через это пройти (а к тому же, - нужно проходить через это много раз...). И в конце, код будет совсем не похож на тот, что был в начале.
З.Ы. Представте, если после всех трудов Вам кто то скажет: "Ваш код - неоптимизированная груда". Разве Вы обидитесь? :)
Ну, не знаю почему для Вас эти вещи очевидны. Разве Вы это уже реализовали?
Технология о которой мы говорили не описана ни в одной статье по MQL. Или я ошибаюсь и Вы можете дать ссылку?
Если я что-то ещё не реализовал, то это ещё не значит, что я об этом уже не думал и не знаю, как я буду это реализовывать. Просто руки пока не дошли. В отличии от Вас я подробно описываю всё, что я делаю. На это тоже уходит время.
Чтобы что-то реализовать, мне необязательно читать статьи. Если нет готового решения, то я ищу свои методы. Но зато у Вас есть возможность читать статьи. И вместо того, чтобы почитать и не задавать вопросы, на которые в статье даются пояснения, Вы продолжаете "пулять" наугад.
Главное - придти к этой технологии посредством косметической оптимизации невозможно, - нужна "замена фундамента".
Замена фундамента - тяжелейший процесс. Обычно все рушиться, - схемы, взаимосвязи, механизмы... ВСЕ.
В общем, - врагу не пожелаешь через это пройти (а к тому же, - нужно проходить через это много раз...). И в конце, код будет совсем не похож на тот, что был в начале.
С ООП всё иначе. Просто у Вас абсолютный пробел в этой области знаний. То, что у Вас "тяжелейший процесс", с ООП решается достаточно просто.
З.Ы. Представте, если после всех трудов Вам кто то скажет: "Ваш код - неоптимизированная груда". Разве Вы обидитесь? :)
Обиды мне не свойственны. Помню, что один из участников английского форума предположил решение (без реализации), как можно улучшить схему. Я воспользовался им. Тяжелейшего процесса не возникло. С Вашим же подходом Вы ещё долго будете мучить себя хвастаясь некачественной реализацией и сражаясь с ветряными мельницами.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Графические интерфейсы X: Расширенное управление списками и таблицами. Оптимизация кода (build 7):
Код библиотеки нуждается в оптимизации: он должен быть более упорядоченным, а значит — более читаемым и понятным для изучения. Кроме этого, продолжим развивать элементы управления, созданные ранее: списки, таблицы и полосы прокрутки.
Часть схемы библиотеки относительно взаимосвязей между формой и элементами выглядит так:
Рис. 3. Часть схемы библиотеки относительно взаимосвязей между формой и элементами
Автор: Anatoli Kazharski