Обсуждение статьи "Пользовательские графические элементы управления. Часть 3. Формы" - страница 2

 
Urain:

Всё правильно сделал.

С учётом возможностей МЕ вполне удобно, японский минимализм в эпоху тотального кича, всё есть, ничего лишнего.

Кто желает перебирать объекты циклом, вполне может реализовать постфиксную оболочку где прописать всё что душеньке пожелается.


Николай, вы считаете, что в MQL5 вот это выглядит опрятно и согласно возможностям ?


         void OnHideEvent(){
            // 7. Вызов метода Hide() для всех элементов управления формы
            m_hm.Hide(); 
            m_vm1.Hide(); 
            m_vm2.Hide(); 
            m_vm3.Hide();             
            m_fr1.Hide();
            m_fr2.Hide();               
            m_ib.Hide();
            m_sib.Hide();
            m_dib.Hide();
            m_cb.Hide();  
            m_chb.Hide();  
            m_rg1.Hide();  
            m_rg2.Hide();  
            m_lms1.Hide();
            m_lms2.Hide();
            m_but.Hide();
         }

        void OnWindowChangeEvent(int aSubWindow){
            // 8. Вызов метода SetSubWindow() для всех элементов управления формы. Номер подокна находится в аргументе aSubWindow.
            m_hm.SetSubWindow(aSubWindow);
            m_vm1.SetSubWindow(aSubWindow);
            m_vm2.SetSubWindow(aSubWindow);
            m_vm3.SetSubWindow(aSubWindow); 
            m_fr1.SetSubWindow(aSubWindow);
            m_fr2.SetSubWindow(aSubWindow);            
            m_ib.SetSubWindow(aSubWindow);
            m_sib.SetSubWindow(aSubWindow);
            m_dib.SetSubWindow(aSubWindow);
            m_cb.SetSubWindow(aSubWindow);
            m_chb.SetSubWindow(aSubWindow);
            m_rg1.SetSubWindow(aSubWindow);
            m_rg2.SetSubWindow(aSubWindow);
            m_lms1.SetSubWindow(aSubWindow);
            m_lms2.SetSubWindow(aSubWindow);
            m_but.SetSubWindow(aSubWindow);
            
         }

 
sergeev:

Николай, вы считаете, что в MQL5 вот это выглядит опрятно и согласно возможностям ?

Не,  японцы против.  Должно быть ровно в три строчки.
 
sergeev:

Николай, вы считаете, что в MQL5 вот это выглядит опрятно и согласно возможностям ?

Если влом набивать воспользуйся шаблоном.

Не стоит сильно увлекаться реализацией всех возможностей, мы ведь пишем коды а не создаём картины из букав.

Не вижу проблем.

 

та вобщем то это просто мнение. Мне ближе картины из кода. Эстет блин. :)
 
sergeev:

та вобщем то это просто мнение. Мне ближе картины из кода. Эстет блин. :)

По сути Integer даёт API с уровнем абстрагирования чуть ниже чем вам хотелось.

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

 
papaklass:

 

Зря Вы пошли на попятную.

потому что есть еще профессиональная этика. Интегер профи и его учить не надо.

Но если доктор сказал в морг, значит в морг.

 
Urain:

По сути Integer даёт API с уровнем абстрагирования чуть ниже чем вам хотелось.

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

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

 

 
papaklass:

 

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

 Господин sergeev, впав в некоторое принципиально-позиционое заблуждение, предлагает нечто типа объединения в одном массиве переменных типа bool, int, double, string и т.д.

Вы же, господин, papaklass, как истиный троль, слышите звон, да не знаете где он. 

Документация по MQL5: Основы языка / Типы данных / Целые типы / Тип bool
Документация по MQL5: Основы языка / Типы данных / Целые типы / Тип bool
  • www.mql5.com
Основы языка / Типы данных / Целые типы / Тип bool - Документация по MQL5
 
Integer:

 Господин sergeev, ... , предлагает нечто типа объединения в одном массиве переменных типа bool, int, double, string и т.д.

... 

Такое в принципе возможно, НО

такая универсализация приводит к перерасходу ресурсов в конечной реализации. Графика и так тяжела по ресурсам.

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

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

 
Urain:

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

Имхо, ты неправ. Дмитрий тоже неправ, Алекс тоже :) . (Все неправы! )))) )

Опять же имхо, Дмитрий выбрал оптимальный вариант по трудозатратам написания\использования.

Написать что-то более простое в использовании (не в понимании!) будет гораздо сложнее.

Причина обращения: