MQL ile yazılmış kullanıcı arayüzleri galerisi - sayfa 42
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Eklendi:
Menü pencereleri artık her zaman grafik alanının içinde kalıyor ve görünümün dışına çıkmıyor. Örnek:
GRAFIĞIN SAĞ SINIRININ ÖTESINE GEÇMEYIN:
GRAFIĞIN ALT SINIR ININ ÖTESINE GEÇMEYIN:
Öncelikli geliştirme yönergelerinin olmaması hiçbir zaman iyi sonuçlara yol açmaz. Tüm profesyonel geliştiricilerin bildiği temel bir gerçek. 4 yıl önce tasarımcının bitmiş bir versiyonunu ortaya koyamadım çünkü tamamlamak için bir planım yoktu. Eğer bir planım olsaydı, her şey çoktan bitmiş olurdu. Projeyi durdurmamın bir sonraki nedeni, forumdaki diğer insanların fikirleriyle yapılan sonuçsuz tartışmalar. Programlamadaki yaklaşımlar veya GUI 'nin gerekliliği-gereksizliği gibi tartışmalar... Ne yazık ki bu gereksiz bir zaman kaybıydı.
Peki bu proje nasıl tamamlanacak? Bu sorunun cevabı çok önemli çünkü daha fazla geliştirme için yön seçimini belirliyor.
Ve böylece, sunduğum gibi:
1. Arayüz elemanlarının yazılım kontrolü.
Bu şu anda ana görevlerden biri. Artık kullanıcı API dosyasında yalnızca GUI olaylarını "yakalayabiliyor", ancak öğe özelliklerini veya parametre değerlerini alamıyor/değiştiremiyor. Karmaşıklığı tarttığımızda, görevin kolay olduğunu ve bir sonraki sürümden önce çözüleceğini söyleyebilirim. Kullanıcıya geniş bir GUI öğeleri ve pencere özellikleri kümesine programatik erişim sağlayın.
2. Düzenli ve dinamik tablolar .
Düzenli tablolar zaten uygulanmıştır. Çalışmaları defalarca test edilmiştir. Sütunları ve satırları sürükleyip bırakma (tablodaki yerlerini değiştirme), tablo satırlarını daraltma/genişletme (T_FOLDER öğesi ekleme) veya sütunları gizleme/gizleme gibi özellikler çalıştı. Kontrollerin tabloya otomatik entegrasyonu çalıştı. Örneğin, onay kutuları, açılır listeler, düğmeler, kaydırıcılar, düğmeli giriş alanları ve basit giriş alanları - grup başlığına IS_TABLE anahtar sözcüğü eklendiğinde hepsi tabloya kendiliğinden entegre edildi. Hücrelerdeki değerler değere göre renklendirilebiliyordu. Tablolar ağaç listelerine bile gömülebiliyordu.
Ancak, tüm eski özellikleri geri getirmek için zaman harcamaya değer mi?
Bunu söylemek zor.
Bence yapılması gereken ilk şey, normal tabloların temel özelliklerini geri getirmek ve iyi çalıştıklarından emin olmaktır. Gerisi çorap söküğü gibi gelir.
Ancak ciddi bir ticaret robotunun arayüzündeki en önemli şey dinamik tablolardır. Borsadan gelen sonsuz bir veri akışından geçebilenler. Bunları daha önce hiç uygulamadım.
Sonuç: dinamik tablolar bir önceliktir.
(Geliştirmeye başlamamız gerekiyor.)
3. Ağaç listeleri.
Oldukça fark edilen GUI öğesi daha önce birçok kez yeniden yapıldı. Ve her seferinde daha iyi çalıştı. En son sürüm özellikle iyi, ancak henüz bitmedi. Eğer ayrıntılı olarak hatırlarsam, bir ya da iki gün içinde bitirebilirim. Ama bir GUI'de buna ne kadar ihtiyacınız var? Bence zararı olmaz, ancak bunu takıntı haline getirmemelisiniz.
Sonuç: ağaç listesi daha fazla geliştirme için bir öncelik değil.
(Zamanım olduğunda bitireceğim.)
4. Dinamik pencereler.
Temel mekanizmalar - yeniden boyutlandırma, dikey ve yatay kaydırma, ölçeklendirme, ölçeklendirilmiş pencerenin grafik boyutu değişikliğine uyarlanması - zaten iyi çalışıyor. Ancak çok sayıda küçük, can sıkıcı hata var. Tamamlanmış olan dinamik pencereler, büyük dinamik tablolar ve uzun listeler için idealdir.
Sonuç: dinamik pencereleri bitirmek bir önceliktir.
(Heyecanla birkaç ya da üç günlük sıkı bir çalışma gerekebilir).
5. Grup ve tablo küçültücüleri.
G_FOLDER ve T_FOLDER elemanları geçmişte çok iyi çalışmışlardır. Şimdi nasıl çalıştıklarını bilmiyorum, çünkü onları test edecek zamanım olmadı. İlginç bir şekilde, element fenomeni fonksiyonunun en son geliştirilmesinde, ağaç listesinin yönetimini ve bu iki tip daraltıcıyı birleştirdim. Bir işlev üç öğeyi yönetiyordu ve boyutu 400 - 500 satırdan fazla değildi (ki bu benim standartlarıma göre çok fazla değil). Bu işlevi tekrar çalıştırabilirsem (şu anda devre dışı), üç öğe de mükemmel bir şekilde çalışacak. Bir bakalım.
Sonuç: G_FOLDER ve T_FOLDER öğeleri öncelikli değil.
(Fırsatım ve isteğim olursa yapacağım).
Ve şimdi aklıma gelen son öncelikli görev:
6. İşaretleme dilinde yazılmış öğe ve pencere gruplarının şablonlarından oluşan bir dalın oluşturulması.
Bu, kullanıcıların dil hakkında derin bilgi sahibi olmadan bile görevleri çözmek için gerekli arayüzü hızlı ve kolay bir şekilde oluşturmalarına olanak tanıyacaktır.
Daha fazla geliştirme için öncelikler hakkında herhangi bir düşüncesi olan varsa, lütfen paylaşın. Not alacağım.
Evet, program yönetimi en önemlisi, motoru kullanacak herkes için bir zorunluluk.
Benim için dinamik tablolar bir zorunluluk. Arayüze esas olarak olayların ve raporların gerçek zamanlı olarak görselleştirilmesi için ihtiyacım var. Kontroller, bunları yönetmek için çemberleme (filtreler vb.) Bunun uygulanmasıyla motoru entegre etmeye başlayabilirim.
İkinci öncelik tam ekran bir pencere. Ancak bu çok basit - bunu zaten tasarımcıda yaptınız. Bir görev çubuğu ile. Ve geçici olarak mümkün olan en büyük pencereyi kullanabilirim. Boyutu seçmek zorundayım, bu acı verici.
Üçüncü öncelik grafikler. Ne kadar zor olduğunu bilmiyorum. Belki de yeterince esneklerse standart kanvas araçlarını kullanmalısınız. Fast And Furious Easy And Fast v1'den başka bir şey denemedim.
İnşallah motivasyon yeterli olur. Çoğu zaman nefret edenlerle karşılaştıktan sonra kaybolup gidiyor. "İyi insanlar çoğunluktadır, ama kötüler daha iyi organize olmuşlardır".
İkinci öncelik tam ekran bir penceredir. Ancak bu çok basit - bunu zaten tasarımcıda yaptınız. Bir görev çubuğu ile. Ve geçici olarak mümkün olan en büyük pencereyi kullanabilirim. Acı verici olan boyutları seçmem gerekiyor.
Üçüncü öncelik ise grafikler. Bunun ne kadar zor olduğunu bilmiyorum. Belki de yeterince esneklerse standart kanvas araçlarını kullanmalısınız. Hızlı ve Öfkeli Kolay ve Hızlı v1 dışında hiç denemedim.
İnşallah motivasyon yeterli olur. Çoğu zaman da nefret edenlerle karşılaştıktan sonra kaybolup gider. "İyi insanlar çoğunluktadır, ama kötüler daha iyi organize olmuşlardır".
1. Programatik öğe yönetimi bir sonraki sürümde olacak. Geçici olarak 7 - 10 gün içinde.
2. Dinamik tablolar "geliştirme aşamasında". Ne kadar süreceğini henüz söyleyemem. Süreç çok hızlı olabilir.... ya da o kadar hızlı olmayabilir. Bilinmiyor.
3. Zaten tam ekran bir pencereniz var. Bunu deneyin. Pencere özelliklerinde "AYARLAR" yerine "DİNAMİK" yazın. Test edin ve izlenimlerinizi yazın.(Sadece oluşturucunun saha sürümü versiyonuna gidin). Pencerenin kenarlarını çekerek boyutu değiştirebilir veya üst düğme ile yakınlaştırabilirsiniz. Üst çubuğa (pencere adının olduğu yere) çift tıklayarak ya da pencereyi "kapağından" tutup kendini ölçeklendirene kadar yukarı sürükleyerek bir seçenek var. Aynı manipülasyonlar diğer şekilde de çalışır.
4. Pencerenizin API dosyasını yazdırın ve buraya gönderin. Tabloların orada nasıl yazdırıldığına bakacağım ve anlayacağım. Bu, gelecekteki yazılım bağlantısı uygulaması için önemlidir.
5. Özel grafikler hakkında ciddi olarak düşüneceğim. Anatoly'nin uygulamasını gördüm, ancak bu öğeyi çoğaltmaya çalışmadım.
Dinamik bir pencere ile çalışırken önemli bir nüans:
Pencere V_BOX türündeki öğeleri kabul etmez, çünkü bunlar kendi tuvallerini içerir. Bu, bir tuvalin diğerinin üzerine binmesine neden olur. Bu nedenle, bu öğe tüm i, IN, "V1", . satırlarıyla birlikte yorumlanmalıdır.
Yani, V_BOX eleman ına yerleştirilen gruplar sadece "MF" üzerindeki pencerede olmalıdır. Özellikle i, IN, "V1" satırını yorumlamanıza gerek yoktur.
Eğer çalışmazsa, yarın size daha ayrıntılı olarak göstereceğim. Resimlerle.
Ayarlar penceresinin dinamik bir pencereye dönüştürülmesine bir örnek:
(resmin üzerine tıklayın)