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
Bana gelince, üyeleri ürün satışlarından belirli bir dereceye kadar kazanç sağlayacak bir ürün geliştirme ekibi oluşturmak daha kolay (belki birisi projenin ideoloğu, biri hisse için finanse ediyor, biri programları).
Eh, herkes maddi olarak motive olduğu için, proje çerçevesinde arayüz için gerekli kütüphaneleri uygulayın.
Bana gelince, üyeleri ürün satışlarından belirli bir dereceye kadar kazanç sağlayacak bir ürün geliştirme ekibi oluşturmak daha kolay (belki birisi projenin ideoloğu, biri hisse için finanse ediyor, biri programları).
Eh, herkes maddi olarak motive olduğu için, proje çerçevesinde arayüz için gerekli kütüphaneleri uygulayın.
Şubeyi okudum ve neden gerekli olduğunu anlamadım - Tuval üzerine sıfırdan bir düğme çizmek. Duygusuz anlatabilir misin?
MT geliştiricileri her şeye kadir olmadığından ve onları küçük İstek Listesi ile zorlamak zaman alıcı olduğundan
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.
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 - fareyi nesnenin üzerine getirin
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.
Kapsamlı, teşekkürler!
@Igor Volodin , @Combinator, @Anatoli Kazharski
Peki o zaman, ağrılı olanla başlayacağım)
Beni en çok endişelendiren soru, oluşturma parametrelerini depolamak için bir tür genellik/soyutlamadır.
----
anladığımız gibi, tüm kontroller yazı tipini, arka plan rengini ve metin rengini vb. eşit olarak kullanır.
Tüm bu parametreler tüm kontroller için aynı olduğunda, arayüz tek bir konsept ile ortak bir görünüme sahip olur.
Ama onları nasıl saklarsın? sonuçta her zaman tüm parametreleri kullanmayın.
+ sistem, öğelerin yazı tipi ve arka plan renklerini farklı şekilde kullanması gereken farklı durumlara sahip olması nedeniyle karmaşıktır. Yani eleman Aktif iken, fareye tepki vermediğinde (Devre dışı), fare nesnenin üzerindeyken (Over) veya kontrol işaretlendiğinde (Seç). vb.
+ kontrol grupları vardır - kabartmalı (Düğme türünden) ve giriş alanları (Düzenleme, Liste türünden) ve bu, çizimlerinin arka planı olduğunda
----
Mevcut çalışma fikrimde, 5 ana parametre (yazı tipi/boyut, arka plan/kenarlık rengi, kenarlık boyutu) içeren minimal bir sınıf öznitelik öğesi GAttribBase var.
Bu temel öğelerden , durumlar için bu parametrelerin ayarlandığı (Aktif/Devre Dışı/Aşırı/Seç vb.)
Ve şimdi GAttribut farklı öğe türleri için doldurulur - kabartmalı, düzenlenebilir vb.
Böylece render parametrelerini bir kez dolduruyoruz (xml'de saklanıyor), farklı tasarımlar oluşturmak için canlı olarak düzenlenebiliyor ve her kontrol için tanımlamadan global olarak kullanıyoruz.
Tabii ki belirli bir kontrolün kendi render parametrelerini tanımlaması gerekiyorsa, o zaman kontrolde kendi GAttribut nesnenizi oluşturmanız ve istenen renkleri belirtmeniz yeterlidir.
----
Bu model çalışıyor, tek bir tasarıma anında ulaşılıyor, tüm kontroller ortak bir diziden renk alıyor.
Ama bence evrensel değil. Gerçek, kullanıcı için şeffaf olmadığından, bu veya bu kontrolü çizmek için GAttribBase tabanından hangi parametrelerin kullanıldığı.
Kodlayıcının tam olarak hangi rengin değiştirilmesi gerektiğini bilmesi için kontrolün çizim işlevine bakması gerekecektir. Ne stresli.
-----
Genel olarak - bir yandan kodlayıcının renklerle çalışmaktan arınmış olması için hangi fikirler vardır (böylece koyu renkleri hemen kullanır ve başlangıçta bunlarla uğraşmaz)
Öte yandan - böylece ekrandaki bir kontrolü yeniden renklendirmek isterse - oluşturma işlevinin ormanına girmez ve GAttribBase'den ne kullanıldığını ve hangi durumda kullanıldığını aramaz.
@Igor Volodin , @Combinator, @Anatoli Kazharski
Genel olarak - bir yandan kodlayıcının renklerle çalışmaktan arınmış olması için hangi fikirler vardır (böylece koyu renkleri hemen kullanır ve başlangıçta bunlarla uğraşmaz)
Öte yandan - böylece ekrandaki bir kontrolü yeniden renklendirmek isterse - oluşturma işlevinin ormanına girmez ve GAttribBase'den ne kullanıldığını ve hangi durumda kullanıldığını aramaz.
Tamam, konular.
Örneğin, uygulamamızın ana nesnesi, buna App diyelim, bir ConcreteTheme nesnesi ile ilişkilendirilir.
Tema nesnesi nedir:
renkler (arka plan, ön plan, devre dışı, etkin vb.), temel boyutlar, standart durumlar için yazı tipi boyutları: başlık boyutu, ortak boyut, vb. , sprite'lar: paneller, düğmeler, onay kutuları vb.
Yeni konu - değişen değerlere sahip yeni sınıf/yapı. Ancak temaların yalnızca belirli parametreleri geçersiz kılarak devralınabilmesi daha iyidir.
Gerisi, her kontrolün varsayılan olarak ihtiyaç duyduğu tema nesnesinin değerlerinden birini kullandığı bir kontrol hiyerarşisidir. Geçersiz kılmak gerekirse - yeni değeri belirterek bu özellikle çalışma yöntemini çağırın.
Örneğin SetBgColor(XRGB(255,0,128));
CView - olay düzeyinde temel etkileşim sağlayan ana sınıf
- СRect - koordinatlar
- cPanel'de bgcolor var
- CButton'un bir durum nesnesi vardır, her durum için bg belirtilir
- CText metin rengi ve yazı tipi özelliklerine sahiptir
- Çember
Vb.
Öğeleri tanımlamak için xml kullanmak istiyorsanız,
daha sonra her kontrol veya ilkel sınıf için bir üst sınıf oluşturmanız gerekir, buna özniteliklerin (bgcolor="(255,0,128)") karşılık gelen yöntemlerle eşleneceği bir "yapı konteyneri" diyelim ( SetBgColor(attrValue) ) sınıfın. Bu tür yapı kapları, XML ayrıştırıcısı tarafından bağlanır, çıktıda gerekli değerlerle başlatılan bir kontrol nesnesi alırız veya hiçbir şey belirtilmemişse varsayılan olur.
burada Tema benimkiyle aynı - farklı kontrol türleri ve durumları için bir dizi GAttributs .
ancak kodlayıcı için şeffaflığa yönelik ilk adımı zaten öneriyorsunuz - işleme özelliklerini değiştirmek için belirli bir kontrole işlevler ekleyin (SetBgColor, vb.)
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?
Diyelim ki GattribBase bazında belirli bir kontrol için (örneğin, bir düğme), sadece arka plan rengini ve boyutunu kullanıyoruz ve geri kalan parametreler kenarlık kalınlığı vb. bu kontrolde kullanılmaz.
Yani, tüm kontroller için bir temel öğeniz var mı? infa "tüm durumlar için" nerede saklanıyor, yoksa tüm kontrollerin evrensellik yükü olmadan yalnızca kendi parametreleri mi var?
...
Genel olarak - bir yandan kodlayıcının renklerle çalışmaktan arınmış olması için hangi fikirler vardır (böylece koyu renkleri hemen kullanır ve başlangıçta bunlarla uğraşmaz)
Öte yandan - böylece ekrandaki bir kontrolü yeniden renklendirmek isterse - o zaman işleme fonksiyonunun ormanına girmez ve GAttribBase'den ne kullanıldığını ve hangi durumda kullanıldığını aramaz.
Her öğe için varsayılan değerleri ayarlayın. Kullanıcının bir şeyi değiştirmesi gerekiyorsa, öğenin her özelliği için yeni bir değer ayarlama yöntemi olmalıdır. Ben şimdi bu şekilde yaptım.
Bu henüz yok:
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. )