![MQL5 - MetaTrader 5 müşteri terminalinde yerleşik ticaret stratejileri dili](https://c.mql5.com/i/registerlandings/logo-2.png)
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
(1) özellik ve değeri veya (2) özelliği, değiştiriciyi ve değeri ayarlamak istediğiniz ElementSet .
evet, kontrolün özelliklerine erişim çerçevesinde evrenseldir.
Genel olarak, PropGet/Set, devralınan arabirim başlangıçta bilinmediğinde şablon sınıflarıyla çalışmak için iyi bir mekanizmadır.
Ancak tartışmayı asıl soruma geri döndürmek istiyorum - kontrollerin renk şemasına göre programcı için "hızlı bir başlangıç" nasıl yapılır?
Ve işlevsel bir sınıf (SetBgColor veya SetProp(Enum_Color, ) vb.) yerine daha evrensel bir nitelik sınıfını uygulamak mümkün müdür?
Böylece tüm kontroller tek bir evrensel öznitelik sınıfına atıfta bulunur, ancak aynı zamanda kodlayıcı, hangi kontrolün hangi renkleri kullandığını kolayca anlayabilir.
Ama bütün bunlar benim planımla ilgili mantığım. Yeni bir aşamaya geçişe başladığımda bunun hala çok değişeceğini göz ardı etmiyorum. Bu nedenle, yukarıda yazdığım her şey, burada tartışılan konu çerçevesinde artık alakalı olmayabilir. )
Prensip olarak katılıyorum, hangi renklere sahip olduğu ve nelerin değiştirilebileceği açık olacak.
o zaman böyle bir soru - Tema, kullanılmayan parametrelerin fazlalığı anlamına mı geliyor?
Evet, tüm seçenekler için gereksiz. Ancak daha sonra bir öncekindeki değerleri yeniden boyayarak ve değiştirerek yeni bir tema oluşturmak uygundur. Windows'taki temalar gibi.
not
Ve mevcut konuda kullanılanlardan farklı olan bazı değerlerin kodlayıcı tarafından kütle değişimi hakkında şüpheliyim. Delphi'de yapmaya çalıştıkları ilk şeyin arayüzü kendi renkleriyle renklendirmek olduğu ve daha sonra sistem teması değiştirildiğinde değişmeyen bir projeyi hatırlatıyor.
Ve neden stilleri bir yere bulaştıralım? Tema sınıfını mevcut olanlardan birinden devralın ve içinde yalnızca değiştirilmesi gereken değerleri geçersiz kılın.
böyle bir CSS teknolojisi var
1) bilinen ve iyi belgelenmiş
2) tanıdık ve evrensel
3) prensipte, etiketler == kontroller, bu da onu görevimize uygun hale getirir
deneyin, amaçlandığı gibi çalışması gerekir.
böyle bir CSS teknolojisi var
Ardından hemen LESS / SCSS'ye (SASS) bakın
Ardından hemen LESS / SCSS'ye (SASS) bakın
Phew, lös görünüşte iyidir, ancak işlevselliği gerekli değildir. tercüman yapmayın.
Biz sadece stilleri bir basamakta ^ seçici olarak ^ noktasal olarak oluşturma ve yeniden tanımlama ilkesini alıyoruz - bunu nasıl yapıyorlar.
Ve duyarlı tasarım (farklı çözünürlükler için tasarım) olasılığını ortaya koyduğunuzdan emin olun. CSS'deki Medya Sorgularına Bakın
Ayrıca, bazı parçalar sabit boyutlara sahip olabilirken, diğerleri kendilerine sunulan mesafeye kadar uzanabilir.
Sevgili forum kullanıcıları, kimsenin motivasyonunu kırmak gibi bir niyetim yok, ama bence, tartışılan teknoloji o kadar karmaşık ki, ortak farklı çabalarla uygulanamaz. Hepimizin anlayış, profesyonellik ve yaklaşım düzeyleri farklı olduğu için bu çabaları etkili bir şekilde birleştiremeyeceğiz... Ayrıca mesafeler ve hatta ülkelerle de ayrıyız.
Benim sonucum, bu teknolojinin üzerinde uzun ve sıkı çalışan yalnız bir geliştirici tarafından uygulanabileceğidir. Belki bir yıl değil. Ancak bu kişinin bu teknolojiyi kitle kaynaklı hale getirmesi pek mümkün değil, çünkü çok fazla çaba harcadı, ruhunu verdi ve bu işle kendini tüketti... Bu onun projesi ve özgürce dağıtmama hakkına sahip. (Belki ilk başta, ama her zaman değil).
Bu teknolojinin MQL'de zaten uygulandığını düşünüyorum.
not Öyle olsa bile, neden tekrar uygulamaya çalışmıyorsunuz? ))
Bu neden yararlı olabilir:
1. Bitmap üzerindeki arayüz hızlıdır. O kadar hızlı ki, sistemden neredeyse ayırt edilemez. Örneğin, degradelerle yarı saydam öğeler uyguladım ve hareket ettiklerinde bile , renk karıştırma ve yarı saydam gradyanlara sahip diğer nesnelerdeki alfa kanalını hesaba katarak görünür gecikmeler olmadan sorunsuz bir şekilde oluşturulurlar.
2. Arayüz ölçeklenebilir. Uygulamayı karmaşıklaştırabilirsiniz ve çok sayıda grafiğin kaldırılması ve oluşturulması nedeniyle yavaşlamaz. nesneler. Yeniden çizmenin maliyeti minimumdur, bu sadece saniyenin binde birinde bir resim değişimidir.
3. Hazır kontroller oluşturabilir ve yenilerinin oluşturulabilmesini sağlayabilirsiniz. kendi etkinlik havuzunuzu sağlayabilirsiniz, örneğin:
OnMouseDown - LMB'ye basıldı
OnMouseUp - LMB'ye basıldı
OnMouseHoverOn - bir nesnenin üzerine gelindi
OnMouseHoverOut - fare imlecini nesneden uzaklaştırdı
OnMouseClick - etki nesnesinin sınırları içinde LMB'ye basıldı ve serbest bırakıldı
OnMouseDblClick, etkilenen nesne içinde LMB'ye çift tıklayın
OnDragStart - LMB'ye basıldığında hareketin başlangıcında 1 kez meydana gelen bir olay
OnDragMove - LMB ile hareket sürecinde oluşturulan olay
OnDragEnd - LMB ile taşındıktan sonra oluşturulan olay
OnPut - nesne başka bir nesneye atıldı
OnGet - nesneye başka bir nesne atıldı
OnFocus - nesne odak aldı
OnBlur - nesne odak kaybetti
OnResize - nesnenin boyutu değişti
OnParentResize - nesnenin ebeveyninin boyutu değişti
OnKeyPress - bir tuşa basıldı
OnChange - alan değeri değişti
vb.
Aşağıdakileri biraz abartıyorsunuz:
Bitmap çizim hızı, boyutuna bağlıdır. Bir parçayı yeniden çizerken, pencereyi temsil eden tüm bitmap'i yeniden çizerseniz, tepki yavaş olacaktır (işaretli). Açık çözüm, yalnızca parça alanını yeniden çizmektir.
Ancak, bir pencereyi temsil eden bitmap'in yalnızca bir bölümünü yeniden çizmek için, bitmap'in dijital maskesi bellekte (bir dizide) saklanmalıdır. Ardından, bu maskede gezinmeniz ve içinde istediğiniz ayrıntıyı bulmanız gerekir . Ancak, birçok pencere olabileceğini lütfen unutmayın. Şimdi tüm pencerelerin maskelerini depolamak için gereken bellek miktarını tahmin edin... Hangi pencerelerin hatırlanacağını ve hangilerinin ne zaman "unutulacağını" seçecek bir öncelik sistemi oluşturabilirsiniz. Ancak, bu kolay bir konu değildir.
Anlayın, yeniden çizme, bir dizideki değerleri yeniden yazmaktır ve 1000000 değeri (pencere görüntüsündeki ve bitmap'teki yaklaşık piksel sayısı) yeniden yazmanız gerekirse, bunlar "saniyenin binde biri" olmayacaktır, ama saniye. Bu nedenle - pencereyi yalnızca bir kez tamamen çizmeniz, belleğe ve ardından olaylara kaydetmeniz, - her nesneyi ayrı ayrı yeniden çizmeniz gerekir. O zaman hız çok yüksek olacaktır.
Görünüşe göre yalnızca bireysel nesneleri uygulamışsınız, ancak bir pencere oluşturmayı deneyin ve öğelerinizin etkileşimini orada uygulayın. Neyden bahsettiğimi anlayacaksın.
Bahsettiğiniz olaylara gelince, bunların programda uygulanması çizim kontrollerinin teknolojisi ile ilgili değildir ve herhangi bir arayüzde bulunmalıdır.
...
Görünüşe göre yalnızca bireysel nesneleri uygulamışsınız, ancak bir pencere oluşturmayı deneyin ve öğelerinizin etkileşimini orada uygulayın. Neyden bahsettiğimi anlayacaksın.
...
Aşağıdakileri biraz abartıyorsunuz:
Bitmap çizim hızı, boyutuna bağlıdır. Bir parçayı yeniden çizerken, pencereyi temsil eden tüm bitmap'i yeniden çizerseniz, tepki yavaş olacaktır (işaretli). Açık çözüm, yalnızca parça alanını yeniden çizmektir.
Ancak, bir pencereyi temsil eden bitmap'in yalnızca bir bölümünü yeniden çizmek için, bitmap'in dijital maskesi bellekte (bir dizide) saklanmalıdır. Ardından, bu maskede gezinmeniz ve içinde istediğiniz ayrıntıyı bulmanız gerekir . Ancak, birçok pencere olabileceğini lütfen unutmayın. Şimdi tüm pencerelerin maskelerini depolamak için gereken bellek miktarını tahmin edin... Hangi pencerelerin hatırlanacağını ve hangilerinin ne zaman "unutulacağını" seçecek bir öncelik sistemi oluşturabilirsiniz. Ancak, bu kolay bir konu değildir.
Anlayın, yeniden çizme, bir dizideki değerleri yeniden yazmaktır ve 1000000 değeri (pencere görüntüsündeki ve bitmap'teki yaklaşık piksel sayısı) yeniden yazmanız gerekirse, bunlar "saniyenin binde biri" olmayacaktır, ama saniye. Bu nedenle - pencereyi yalnızca bir kez tamamen çizmeniz, belleğe ve ardından olaylara kaydetmeniz, - her nesneyi ayrı ayrı yeniden çizmeniz gerekir. O zaman hız çok yüksek olacaktır.
Görünüşe göre yalnızca bireysel nesneleri uygulamışsınız, ancak bir pencere oluşturmayı deneyin ve öğelerinizin etkileşimini orada uygulayın. Neyden bahsettiğimi anlayacaksın.
Bahsettiğiniz olaylara gelince, bunların programda uygulanması çizim kontrollerinin teknolojisi ile ilgili değildir ve herhangi bir arayüzde bulunmalıdır.
Küçük bir açıklama yapmak istiyorum:
İlk önce tüm unsurlarıyla birlikte bir dijital pencere maskesi oluşturuyoruz. Ardından, ResourceCreate() kullanarak bitmap'i oluşturuyoruz. Grafikte bizim penceremiz var.
Ardından, fareyi bu pencerenin arabirimi üzerinde hareket ettiririz ve örneğin (_Object_Pointed) öğesindeki hover olayını yakalarız .
Nesne etkileşimini uygulamak için 2 yaklaşım anlatacağım, biri kötü, diğeri daha iyi:
1. Penceremizin dijital maskesi ilk oluşturmadan sonra diziye kaydedilmediyse, bu pencerenin resminin bazı ayrıntılarını değiştirmek için tamamen yeniden oluşturmanız gerekir. Yani, inşaatı yeniden dijitalleştirmek. Bu başlı başına zaman alır, çünkü diziyi ResourceCreate()'e geçirmek için tüm pencere detaylarının piksel renk değerleriyle başlatmanız gerekir. Pencere ne kadar büyükse ve içerdiği ayrıntı ne kadar fazlaysa, o kadar uzun sürer (yaklaşık 250 milisaniye ila 2 saniye). Ve böylece, her öğenin her olayında. Bu varyant çok kusurlu.
2. Dijital maske bir dizide saklandıysa, yalnızca bu pencerenin belirli bir ayrıntısıyla ilgili olan değerlerin yeniden başlatılması gerekir. Bu kısmı dizide buluyoruz ve değerlerinin üzerine yazıyoruz. Ardından diziyi ResourceCreate()'e gönderiyoruz ve hemen sonucu alıyoruz.
Aslında tüm teknoloji bu. Hemen hemen))