Discusión sobre el artículo "Controles gráficos personalizados. Parte 3. Formularios" - página 2

[---]

Urain:

Hice todo bien.

Dadas las posibilidades de ME es bastante conveniente, minimalismo japonés en la era del kitsch total, todo está ahí, nada superfluo.

Aquellos que quieren hacer un bucle a través de objetos pueden implementar un shell postfix donde pueden escribir lo que quieran.

Nikolay, ¿crees que en MQL5 esto se ve ordenado y de acuerdo a las posibilidades?

         void OnHideEvent(){
            // 7. Llamada al método Hide() para todos los controles del formulario
            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);
            
         }

[Vladimir Gomonov]

sergeev:

Nikolay, ¿crees que esto parece limpio y de acuerdo con las posibilidades en MQL5?

No, los japoneses están en contra. Debe ser exactamente tres líneas.

[Mykola Demko]

sergeev:

Nikolay, ¿crees que en MQL5 esto se ve ordenado y acorde a las posibilidades?

Si no tienes suficiente tiempo para escribir, utiliza una plantilla.

No hay que ser demasiado aficionado a la realización de todas las posibilidades, estamos escribiendo códigos, no la creación de imágenes a partir de letras.

No veo ningún problema.

[---]

es sólo una opinión. Yo soy más de pintar códigos. Esteta. :)

[Mykola Demko]

sergeev:

es sólo una opinión. Yo soy más de pintar códigos. Esteta. :)

De hecho, Integer da API con un nivel de abstracción un poco más bajo de lo que querías.

Bueno, refínalo por ti mismo, ponlo en el codebase y quizás tu API sea más popular.

[---]

papaklass:

No deberías haberte echado atrás.

porque también está la ética profesional. Entero es un profesional y no necesita que le enseñen.

Pero si el médico dice morgue, entonces morgue será.

[Dmitry Fedoseev]

Urain:

De hecho, Integer da API con un nivel de abstracción un poco más bajo de lo que querías.

Bueno, refínalo a tu gusto, ponlo en el código base y quizás tu API sea más popular.

Una biblioteca en la que cada clase tendrá el mismo conjunto de métodos, la mitad de los cuales no serán válidos, es poco probable que se haga popular.

[Dmitry Fedoseev]

papaklass:

No deberías haberte echado atrás. Tienes toda la razón. Una persona que se posiciona como un programador guay y profesional está obligada a escribir un código correcto y bonito. Los principiantes tendrán algo de lo que aprender.

El señor sergeev, habiendo caído en algún error de concepto fundamental y posicional, sugiere algo como combinar variables como bool, int, double, string, etc. en un array.

Pero usted, señor papaklass, como un verdadero troll, oye un ruido pero no sabe dónde está.

[Mykola Demko]

Integer:

Sr. Sergeev, ... propone algo como combinar en un array variables como bool, int, double, string, etc.

...

Esto es posible en principio, pero

tal universalización conduce a un consumo excesivo de recursos en la implementación final. Los gráficos ya consumen muchos recursos.

Y por este precio sólo compras una clase más abstraída, por cierto, no es un hecho que vaya a ser más comprensible en su uso.

Pero es un hecho que cuanto más compleja es la implementación, más buggy es.

[TheXpert]

Urain:

Y por este precio usted compra sólo una clase más abstracta, por cierto, no es un hecho que será más comprensible en uso.

Imho, usted está equivocado. Dmitry se equivoca también, Alex se equivoca también :) . (¡Todo el mundo se equivoca! )))) )

Una vez más, imho, Dmitry eligió la mejor opción en términos de mano de obra para escribir / usar.

Escribir algo más sencillo de usar (¡no de entender!) sería mucho más difícil.