MQL ile yazılmış kullanıcı arayüzleri galerisi - sayfa 53
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Rether, gelecek sürümlerde kataloğu İngilizce olarak değiştirmeyi düşünür müsün? Katalog adlarını içeren kaynak kod dosyaları metin ile değiştirilir.
Evet, elbette. Bunu zaten düşündüm. Katalog isimlerinin İngilizce olduğu özel bir sürüm yapacağım.
Dosyaları kontrol etmiyorum, sadece buradaki yorumları kontrol ediyorum. Ancak benim için bu 'gecikme' hız ile ilgili değil, yeni kaynağı tamamen oluşturmadan önce ChartRedraw kullanımı ile ilgili gibi görünüyor. Çünkü boş bir tuval ile yanıp sönüyor ve sonra yeni tuvali gösteriyor.
Elbette. Biraz düşündüm. İngilizce katalog adını içeren özel bir sürüm yapacağım.
İngilizce kataloglarla özel bir sürüm yapmamanızı, ancak böyle bir İngilizce sürüm yapmanızı öneririm, sadece kataloğun adını İngilizce olarak değiştirin ve bir sonraki adım dosya adını İngilizce olarak değiştirmek olacaktır ve kaynak kodunu hala Rusça yazacaksınız.
Katılıyorum. Yavaş yavaş dizinlerin İngilizce isimlerine geçeceğim. Bu şekilde daha mantıklı olacak.
Dosyaları kontrol etmedim, sadece buradaki yorumları kontrol ettim. Ancak benim için bu "gecikme" hız ile ilgili değil, yeni kaynak tam olarak oluşturulmadan önce ChartRedraw'ı kullanmakla ilgili gibi görünüyor. Çünkü boş bir tuval yanıp sönüyor ve ardından yeni tuvali gösteriyor.
İlginç bir fikir, test etmeye çalışacağım. Teşekkürler.
Ve böylece, bir güncelleme...
Bu bir ara güncellemedir. Bir sonraki sürümü birkaç gün içinde yayınlayacağım. Kontrollerle program etkileşimi için yeni işlevler olacak.
Şunu söylemeliyim: İki yapı üzerinde çalışıyorum - 2470 ve yeni yapı. Geliştirmenin çoğu eski yapı üzerinde yapılıyor. Derleme orada daha hızlı - 4 saniyeye karşılık 26-32 saniye. Yeni yapı biraz farklı çalışıyor ve bu görsel olarak fark edilebiliyor. Bazen daha hızlı, bazen daha yavaş. Belki de sadece öyle hissettiriyordur. Bir fark bulmak zor, ama bana orada gibi görünüyor. Eski yapıdaki arayüz uçuyor. Yenisinde. Neredeyse uçuyor. Belki de alıştığım için böyle olduğunu düşünüyorum.
Ancak, bazı nüanslar var. Örneğin, grafik yüksekliği ve genişliğinin yanlış değerleri döndürüldüğünde, grafiklerin değiştirilmesiyle ilgili bir sorun var. Bu, görev çubuğunun atlamasına neden oluyor. Bu sorunu atlatmayı başardım, ancak görev çubuğu diğer grafik yeniden boyutlandırma olaylarına tepki vermiyor. Sonunda - olduğu gibi bırakmaya karar verdim. Görev çubuğu grafik değiştirildiğinde atlayacak (yanlış değerler döndürme sorunu olduğu sürece), ancak diğer olaylara normal şekilde uyum sağlayacaktır.
Ama hepsi bu kadar değil. Grafik yeniden boyutlandırma olaylarının anında gelmediği ve yarım saniyelik bir duraklama olduğu ortaya çıktı. Bu gecikme, görev çubuğunun yeniden çizilme zamanının üzerine ekleniyor ve iyi bir gecikme elde ediyorsunuz. Burada güçsüz durumdayım.
Şunu söyleyeceğim: elbette grafikleri önemli ölçüde hızlandırdım, ancak kodda hala optimize edilmemiş başka çözümler var. Onlar üzerinde çok çalışıyorum. Çoğunlukla pencere odak geçişi ve yeniden çizim kuyruğu ile ilgili. Bazı gereksiz çağrılar oluyor. Görev çubuğu gecikiyor. Her şeyi olmasa da düzeltmek için zamanım olanları düzelttim. Ancak geri kalanı önümüzdeki birkaç gün meselesi. Bunun dışında geliştirilecek pek bir şey yok... belki sadece kodu güzel kokulu hale getirmek için taramak ve parfümlemek)).
Genel olarak, geriye kalan optimize edilmemiş tüm çözümleri ayıklarsak - uçacaktır... Tabii ki bir MQL programında mevcut olan hızlar dahilinde.
Sürümü ele alalım.
Ve böylece, bir güncelleme...
...
Şöyle söyleyeyim: grafikler elbette önemli ölçüde hızlandı, ancak kodda hala optimize edilmemiş bazı başka çözümler var. Onlar üzerinde çok çalışıyorum. Çoğunlukla pencere odak geçişi ve yeniden çizim kuyruğu ile ilgili. Bazı gereksiz çağrılar oluyor. Görev çubuğu gecikiyor. Her şeyi olmasa da düzeltmek için zamanım olanları düzelttim. Ancak geri kalanı önümüzdeki birkaç gün meselesi. Bunun dışında geliştirilecek pek bir şey yok... belki sadece kodu güzel kokulu hale getirmek için tarayın ve parfümleyin)).
Genel olarak, geriye kalan optimize edilmemiş tüm çözümlerin hatalarını ayıklarsak - uçacaktır ... Tabii ki bir MQL programında mevcut olan hızlar dahilinde.
Tahliyeyi al.
Şunu açıkça belirteyim: burada hızdan bahsediyoruz. Odak değiştirme olayında pencerenin yeniden çizilmesindeki kusurları düzeltirseniz, arayüz hızı bir MQL programının üst sınırında olacaktır. Görev çubuğunun gecikmeleri kısmen düzeltilebilir. İyi bir çözüm buldum - görev çubuğunun mekaniğinde dinamik bir pencere prensibini uygulamak - yeniden boyutlandırıldığında, çerçeve tarafından çekildiğinde yavaşlamaz. Daha hızlı ve daha belirsiz bir şekilde ayarlanacaktır. Ve tabii ki, gereksiz yeniden çizimleri iptal etmemiz gerekiyor. Bu zorunludur. Ancak CHARTEVENT_CHART_CHANGE olaylarının kendileri programa gecikmeli olarak gelirse, görev çubuğu tepkilerinin görünür gecikmesi, bununla hiçbir ilgisi olmamasına rağmen kaçınılmazdır.
Aksi takdirde, arayüz geliştirme ve iyileştirme için birçok yön vardır.
Arayüz hızı hakkında birkaç kelime daha.
Gecikmeleri kontrol etmek ve render frenlerini araştırmak için çok zaman harcadım. Kanvas düzeninden sorumlu blok, ResourceCreate() işlevinde bir kaynak oluşturmaya giden diziyi başlatmadan önce, pencere ayrıntıları üzerindeki döngünün sınırlarını tanımlayacak şekilde oluşturulmuştur. Bunu, gelen olayları kontrol etmek için yapılandırılmış koşul filtrelerinin yardımıyla yapar. Bloğu çağıran her olaya çizim sınırları verilir. Örneğin, imlecin üzerine gelindiğinde öğenin tepki vermesi olayında, yalnızca belirli bir öğenin ayrıntıları üzerinde döngü sınırları olan filtre etkinleştirilir. Blok, alınan görüntü üzerinde yalnızca ayrıntılarını seçer. Ve detaylar üzerindeki döngü sırasında, görüntünün geri kalanı arasından sadece onları seçerek çizer. Doğru elemanın doğru detayını başlatmak ve çizmek için yerleri doğru bir şekilde bulur. Aynı zamanda, görüntü alanının geri kalanını doğru bir şekilde atlar.
Ancak hızlanma sadece bu kadar değil. Blok, renkleri gerekli değerle eşleşiyorsa tuvalin noktalarını başlatmaz. Ayrıca, dizi boyunca "koşmaz", ancak mesafeler üzerinde adım atarak "atlar". Bu, döngüleri yüz binlerce iterasyon kadar azaltır.
Sadece bu da değil. Görüntü dizisi global olduğu için (global düzeyde bildirilir), her zaman son görüntünün değişikliğini hafızasında saklar. Ve aynı tuval üzerinde değişiklikler olmaya devam ederse, her seferinde dizisini temizlemek yerine, depolanan görüntü kullanılır. Kaynak adı bir sonraki olayda değişmezse, ResourceReadImage() işlevini çağırmaya ve tuval dizisini doldurulması için tekrar göndermeye gerek yoktur. Blok, ResourceReadImage() işlevini çağırmadan kalan verilerle çalışmaya devam eder ve değişiklikten sonra resmi ResourceCreate() ile günceller.
Bu, ResourceReadImage() çağrılarında çok zaman kazandırır. Ayrıca diziyi temizlemek ve doldurmak için de. Küresel belleğin iyi bir kullanımı, değil mi?
Pencereleri yeniden çizerken, blok hiç çağrılmaz. Pencere bileşenleri silinir ve oluşturulur ve önceden kaydedilmiş kaynaklar bunlara eklenir. Render işlemi yoktur.
Tüm bunlarla birlikte, hala gecikmeler var ve bunlar kaçınılmaz. Neler olup bittiğini açıklayayım.
Bir pencerenin ilk açılışında veya bir sekmenin ilk açılışında veya bir ağaç listesinde veya büyük alanların küçültülmesinde/modellenmesinde, tuvallerin zorunlu olarak tamamen yeniden çizilmesi söz konusudur. Daha sonra birçok kez verimli bir şekilde bağlanabilecek/değiştirilebilecek görüntü kaynakları oluşturma anına kadar, HER ZAMAN BİR kez sıfırdan tam bir görüntü çizmeniz gerekir. İlk çizim HER ZAMAN en uzun olanıdır. Kaydedilecek bir şey yoktur, kaydedilmiş bir görüntü yoktur. İlk açtığınızda her zaman gecikmeler görebilirsiniz. Bu kaçınılmazdır.
Ancak, burada da iyi bir çözüm var: pencere açma gecikmelerini yükleme olayına taşımak. Demek istediğim: yükleme aşamasında arka plandaki kurucu tüm görüntüleri çizer ve bunları önceden kaynaklara kaydeder, böylece açılışta her şey hazır olur. Böylece kullanıcı pencereleri ilk kez açarken herhangi bir gecikme görmeyecektir. Bu elbette harika, ancak bir dezavantajı var. İlk açılıştaki gecikme, yükleme gecikmesine dönüşecek ve süresi artacaktır. Ne kadar olduğunu söylemek zor. Bence ortalama olarak bir saniye içinde. Özel arayüze bağlı olarak değişir.
Bu seçeneğin tercih edilebilir olduğunu düşünüyorum. Tasarımcı/kullanıcı arayüzünün biraz daha uzun süre yüklenmesini tercih ederim, ancak görsel açılış gecikmeleri olmayacak.
Bu konudaki görüşlerinizi duymak isterim.
Eklendi:
İlk yüklemeden sonra arayüz kaynaklarını bir dosyaya kaydetme fikri vardı. Böylecesonraki yüklemeler çok daha hızlı olacaktır, çünkü gerekli kaynaklar zaten tasarımcının/motorun emrindedir. Bunun hakkında düşünmem gerekiyor.