"Özel Grafik Kontrolleri. Kısım 3. Formlar" makalesi için tartışma
İyi ve faydalı bir çalışma, Dimitri. Dördüncü bölüm için bir öneri var: "Form Sihirbazı" veya "Görsel Form Düzenleyici". Bu konuda ne düşünüyorsunuz?
Saygılar, Dimitri. Harika bir iş çıkardınız.
Lütfen v4 sınıflarının bir sonraki sürümü için bazı eleştirileri kabul edin.
1. Temel projede yeterli soyutlama yok. Sahip olduğunuz her kontrolün bağımsız bir birim olarak hareket ettiği ortaya çıktı. Sonuç olarak, örneğin bunları bir dizi halinde birleştiremezsiniz.
2. Bir öğenin her sınıfı artık genel olarak kendine özgü işlevler kümesine sahiptir. Bu iyi bir şey değildir. İşlevleri torunlarda basitçe geçersiz kılınan ortak bir ata olmalıdır. Özellikle de mevcut sınıflarda aynı isimde çok fazla fonksiyon olduğu için. ortak bir ata yapmaktan sizi alıkoyan nedir?
3. Bir temel sınıf ortaya çıkarsa, olay işlemlerini formun dışına koymak yerine torunların içine gizlemek mümkün olacaktır. nesnelerin içinde bir dizi olay yapmak için (web'deki CSS'ye benzer).
Ancak genel olarak, makalenin üç bölümü de ödüle layık, özellikle düğmelere basarken "dürtmeleri" ve öğenin durumuna bağlı olarak basışlara etkileşimli yanıtlarını beğendim.
PS.
Ve hala bitirdiğiniz çok düzeyli menü, bunun üzerine ayrı bir makale gerekli değil, yeni bir makale yazmak için böyle küçük bir görev için çok şişman. Sadece v4 sürümünde bir yükseltme olsun.
CTreeCtrl ağaç sınıfı, MT kitinde sunulan https://www.mql5.com/tr/articles/272 veya CTreeNode makalesinden alınabilir.
- 2011.03.16
- o_O
- www.mql5.com
İyi ve faydalı bir çalışma, Dimitri. Dördüncü bölüm için bir öneri var: "Form Sihirbazı" veya "Görsel Form Düzenleyici". Bu konuda ne düşünüyorsunuz?
Şahsen ben olumlu görüyorum. Ama gerekli mi? Görsel sadece nesnelerin yerleştirilmesini basitleştirir. Düzgün bir şekilde yaparsanız, oluşturulan nesneler için kod oluşturma, değişkenlerin veya sınıfların nesneye bağlanması gerekir. Ve en önemlisi, olay işleme.
Ancak bu soyut olmayan sınıflarda bu yapılamaz. Çok manueldirler. Birçok yerde yeni oluşturulan nesneleri ve bunların işlenmesini yazmak gerekir.
Örneğin olaylar için, sistem ve kullanıcı olarak böyle bir ayrım yoktur - Draw (temel sistem) ve OnDraw gibi - kullanıcıdan kendi çizimiyle ekleme.
Diğer yapılarda (örneğin Joomla!) sadece bir özel fonksiyon OnDraw yoktur. Ve ikiye ayrılır - BeforDraw ve AfterDraw. Yani, programcı EVENT_DRAW sistem olayını işleyebilir - hem sistem çiziminin başlamasından önce hem de bitiminden sonra.
Saygılar, Dimitri. Harika bir iş çıkardınız.
Lütfen v4 sınıflarının bir sonraki sürümü için bazı eleştirileri kabul edin.
1. Temel projede yeterli soyutlama yok. Sahip olduğunuz her kontrolün bağımsız bir birim olarak hareket ettiği ortaya çıktı. Sonuç olarak, örneğin bunları bir dizi halinde birleştiremezsiniz.
2. Bir öğenin her sınıfı artık genel olarak kendine özgü işlevler kümesine sahiptir. Bu iyi bir şey değildir. İşlevleri torunlarda basitçe geçersiz kılınan ortak bir ata olmalıdır. Özellikle de mevcut sınıflarda aynı isimde çok fazla fonksiyon olduğu için. ortak bir ata yapmaktan sizi alıkoyan nedir?
3. Bir temel sınıf ortaya çıkarsa, olay işlemlerini formun dışına koymak yerine torunların içine gizlemek mümkün olacaktır. nesnelerin içinde bir dizi olay yapmak için (web'deki CSS'ye benzer).
Ancak genel olarak, makalenin üç bölümü de ödüle layık, özellikle düğmelere basarken "dürtmeleri" ve öğenin durumuna bağlı olarak basışlara etkileşimli yanıtlarını beğendim.
PS.
4. Çok seviyeli bir menü hala bitmedi, bunun üzerine ayrı bir makale gerekli değil, yeni bir makale yazmak için böyle küçük bir görev için çok şişman. Sadece v4 versiyonunda bir yükseltme olsun.
CTreeCtrl ağaç sınıfı MT kitinde sunulan https://www.mql5.com/tr/articles/272 veya CTreeNode makalesinden alınabilir.
1- Tek tip kontrolleri bir dizi içine toplayabilirsiniz. Birbirine benzemeyen kontrolleri neden tek bir dizide toplamak isteyesiniz ki?
2. Bir temel sınıf (tüm kontroller için bir tane) kullanırsanız, bu, herhangi bir alt sınıfın sahip olabileceği tüm yöntemlere sahip olması gerektiği anlamına gelir. Bağımsız sınıflarda, yöntemlerin açılır listesinde (geliştirme sırasında), yalnızca sınıfta gerçekten var olan yöntemlere sahibiz. Bence bu çok önemli bir nokta. Birinin oturup dikey bir kaydırma çubuğu için SetWidth() yöntemini çağırmaya çalıştığını hayal edebiliyorum.
İkinci argüman - tüm sınıflar doxygen için yorumlanır, eğer bir temel sınıf ve alt sınıflar varsa, dokümantasyonda çok belirgin bir yapılanma olmayacaktır.
"Gözler kapalı" olarak kullanılabilmeleri için hazır çözümler üretmeye çalışıyorum. Yeni bir kontrol oluşturma sürecini hızlandırmak için, tüm zorunlu yöntemleri içeren bir şablon kullanabilirsiniz.
3. Tam olarak anlamıyorum. Bir kontrolün içinde başka bir kontrol varsa, olay işleme gizlenir. Her durumda, her kontrol için Event() metodunu çağırmanız gerekecektir.
4. Bilmiyorum, belki... Menü oluşturmak için özel olarak tasarlanmış kendi sınıfım var, AddNode() çağırmak gerekli değildir, AddItem() çağrılır ve seviye, öğenin adının başladığı boşluk sayısına göre belirlenir. Bir ağaç oluşturma süreci çok açıktır. Şimdiye kadar yorum ve anahtar kontrolündeki ekranla çalışır. Genel olarak, birkaç ağaç menüsü yapabilirsiniz: 1) açılır sekmeleri olan normal bir ana menü gibi, 2) bir sekmenin öğelerini ve en üste giden yolu görüntüleyin, 3) ağaç görüntüsü ile (windos explorer gibi).
1. Şahsen ben bunu olumlu görüyorum. Ama gerekli mi? Görselleştirme sadece nesnelerin yerleştirilmesini kolaylaştırır. Düzgün bir şekilde yaparsanız, oluşturulan nesneler için kod üretmeniz, değişkenleri veya sınıfları nesneye bağlamanız gerekir. Ve en önemlisi, olayların işlenmesi.
2. Ancak bu soyut olmayan sınıflarda bu yapılamaz. Çok manueldirler. Birçok yerde yeni oluşturulan nesneleri ve bunların işlenmesini yazmak gerekir.
Örneğin olaylar için, Draw (temel sistem) ve OnDraw gibi sistem ve kullanıcı olarak böyle bir ayrım yoktur - kullanıcıdan kendi çizimiyle bir ekleme.
Diğer yapılarda (örneğin Joomla!) sadece bir özel fonksiyon OnDraw yoktur. Ve ikiye ayrılır - BeforDraw ve AfterDraw. Yani, programcı sistem olayını EVENT_DRAW - hem sistem çiziminin başlamasından önce hem de bitiminden sonra işleyebilir.
1. Kontrollerin olaylarını işlemek için kodu otomatik olarak oluşturmak ve HScrollBar1_OnChange().... gibi tüm kontroller için olay fonksiyonları almak mümkün olacaktır.
2. Henüz olaylar yok, örneğin, değerler programlı olarak ayarlandığında, olaylar yalnızca kullanıcı tarafından değerler girildiğinde üretilir. Bu yeterli bir minimumdur, ekstra bir şey değildir. Aksi takdirde, kendi başına programlamayı öğrenen biri olaylarla dolup taşacaktır.
İyi ve faydalı bir çalışma, Dimitri. Dördüncü bölüm için bir öneri var: "Form Sihirbazı" veya "Görsel Form Düzenleyici". Nasıl bakıyorsunuz?
... Bölüm 4 için bir öneri var: "Form Sihirbazı" veya "Görsel Form Düzenleyici". Bu konuda ne düşünüyorsunuz?
1. Tek tip kontroller bir dizi halinde bir araya getirilebilir. Neden farklı tipteki kontroller tek bir dizide toplanır?
Her şeyi tek bir döngüye sokmak ve olay hizmetinde belirli türlerden kurtulmak için.
2. Bir temel sınıf (tüm kontroller için bir tane) kullanırsanız, bu, herhangi bir alt sınıfın sahip olabileceği tüm yöntemlere sahip olması gerektiği anlamına gelir. Bağımsız sınıflarda, yöntemlerin açılır listesinde (geliştirme sırasında), yalnızca sınıfta gerçekten var olan yöntemlere sahibiz. Bence bu çok önemli bir nokta. Birinin oturup dikey bir kaydırma çubuğu için SetWidth() yöntemini çağırmaya çalıştığını hayal edebiliyorum.
Temel sınıftaki tüm fonksiyonlar minimum genel işlevselliğe sahip boş durduruculardır. Birisi bilmeden bir öğe için ilgisiz bir işlev çağırsa bile, kesinlikle kötü bir şey olmayacaktır. bu OOP'nin gücüdür. Çok biçimlilik.
İkinci argüman - tüm sınıflar doxygen için yorumlanır, eğer bir temel sınıf ve alt sınıflar varsa, dokümantasyonda bu kadar açık bir yapılanma olmayacaktır.
olacak. sadece farklı olacak... :)
- 2010.03.25
- MetaQuotes Software Corp.
- www.mql5.com
1. Her şeyi tek bir döngüye almak ve olay hizmetindeki belirli türlerden kurtulmak.
2. asıl nokta, temel sınıfın - belirli eylemlerin işlevlerinin uygulanmasına sahip olmamasıdır. temel sınıftaki tüm işlevler, minimum genel işlevselliğe sahip boş durduruculardır. Birisi bilmeden bir eleman için ilgisiz bir fonksiyon çağırsa bile, kesinlikle kötü bir şey olmayacaktır. bu OOP'nin gücüdür. Ancak polimorfizm.
3. olacak. sadece farklı olacak.... :)
1. Hepsi bu kadar mı? Bunun uğruna madde 2 - yöntem dökümü ile uğraşmak için mi?
Alternatifler:
1) Her sınıf için manuel olarak bir Event() çağrısı ekleme ihtiyacı (fare ile bir satır kopyalamak ve noktanın solundaki birkaç harfi değiştirmekten ibarettir) ve aynı zamanda, her sınıfın yöntem listesinde yalnızca bu sınıfa karşılık gelen çalışma yöntemlerimiz vardır, noktaya tıklandığında liste açılır ve her şey açıktır.
2) Tüm sınıfların Event() işlevinin otomatik olarak işlenmesi, ancak yine de OnChartEvent() işlevinden bir işlevin çağrılması gerekecek ve diğer yandan: listedeki yöntemlerin dökümü. Ayrıca, deinit içinde işaretçileri yok etmeniz gerekecektir.
Biraz daha derine ve ileriye bakın, neden tüm Event()'ler tek bir döngüde işlenmelidir, her kontrolün kendi Event()'i için kendi eylemleri olmalıdır, kontroller sadece bir değer girmek için değildir ve sadece her şeyin ekranda hareket etmesini ve titremesini sağlamak için değil, aynı zamanda (ana ölçüde) girilen değerleri programda kullanmak içindir.
3. Bir kontrolün metotlarının yaklaşık yarısını dokümantasyonun bir yerinde, diğer yarısını da başka bir yerinde okumanız gerekecektir.
1. Bu kadar mı? Bunun uğruna, 2. maddeyle - yöntemlerin çöpe atılmasıyla - uğraşmak mı?
Alternatifler:
1) Her sınıf için manuel olarak bir Event() çağrısı ekleme ihtiyacı (fare ile bir satır kopyalamak ve noktanın solundaki birkaç harfi değiştirmekten ibarettir) ve aynı zamanda, her sınıfın metotları listesinde sadece bu sınıfa karşılık gelen çalışma metotlarımız vardır, noktaya tıklandığında liste düşer ve her şey açıktır.
2) Tüm sınıfların Event() işlevinin otomatik olarak işlenmesi, ancak bir işlevin hala OnChartEvent() işlevinden çağrılması gerekecek ve diğer yandan: listedeki yöntemlerin dökümü. Ayrıca, deinit içinde işaretçileri yok etmemiz gerekecek.
Neden tüm Event()'lerin tek bir döngüde işlenmesi gerektiğini, her kontrolün kendi Event()'leri için kendi eylemleri olması gerektiğini, kontrollerin sadece bir değer girmek ve ekranda her şeyin hareket etmesini ve titremesini sağlamak için değil, aynı zamanda (ana ölçüde) girilen değerleri programda kullanmak için olduğunu biraz daha derine ve daha ileriye bakın.
3. Bir kontrolün yöntemlerinin yaklaşık yarısını belgelerin bir yerinde, diğer yarısını da başka bir yerinde okumanız gerekecektir.
Her şeyi doğru yapmışsınız.
ME'nin olanakları göz önüne alındığında oldukça kullanışlı, tam bir kitsch çağında Japon minimalizmi, her şey orada, gereksiz hiçbir şey yok.
Nesneler arasında döngü yapmak isteyenler, istediklerini yazabilecekleri bir postfix kabuğu uygulayabilirler.
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Yeni makale Özel Grafik Kontrolleri. Kısım 3. Formlar yayınlandı:
Bu, grafik kontrollere ayrılmış üç makalenin sonuncusudur. Ana grafik arayüz bileşeninin - form - oluşturulmasını ve diğer kontrollerle birlikte kullanımını kapsar. Kontrol kitaplığına form sınıflarının yanı sıra CFrame, CButton, CLabel sınıfları eklenmiştir.
Form, birkaç düğme OBJ_BUTTON kullanımı ile "Dikdörtgen Etiket" OBJ_RECTANGLE_LABEL grafik nesnelerine dayanmaktadır. Görsel olarak form, form adının ve kontrol düğmelerinin görüntülendiği formun üst kısmında bir çubuk bulunan bir dikdörtgeni (Şekil 1) temsil eder.
Solda formu hareket ettiren (el görselli) bir düğme, sağda küçültme düğmesi (dikdörtgen görselli) ve kapat düğmesi (çarpı görselli) yer alır.
Şekil 1. Form
Formu taşımak için, taşı düğmesine basın (düğme basılan konuma gelir) ve grafikte formun taşınması gereken herhangi bir yeri tıklayın. Sonuç olarak, taşı düğmesi serbest bırakılacak ve form belirtilen yere taşınacaktır (sol üst köşesi tıklanan noktada olacaktır).
Yazar: Dmitry Fedoseev