Canvas üzerinde bir kitle kaynaklı proje yapma - sayfa 13

 
Igor Volodin :


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.

Katılıyorum, ancak libu'yu kitle kaynağı olarak açın)
 
o_O :
İgor Volodin :


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.

Katılıyorum, ancak libu'yu kitle kaynağı olarak açın)
Şubeyi okudum ve neden gerekli olduğunu anlamadım - Tuval üzerine sıfırdan bir düğme çizmek. Duygusuz anlatabilir misin?
 
Alexey Volchanskiy :
Şubeyi okudum ve neden gerekli olduğunu anlamadım - Tuval üzerine sıfırdan bir düğme çizmek. Duygusuz anlatabilir misin?
ObjectCreate ve ResourceCreate arasında seçim yaparken ikincisini seçiyorum.
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.

 
Igor Volodin :

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!

 
Konuyu okudum, ilginç. 3 yıl önce arayüzler hakkında böyle bir yaygara olmaması üzücü.

Kodumu göndermekte bir anlam görmüyorum, çünkü Katılımcılar arasındaki iletişimdeki tembellik ve zorluk nedeniyle girişimin sona erme olasılığı yüksek (ve zaten gözlemleniyorlar), kodum kendisi ve ben (ve topluluk) için revizyon için mahzenler boyunca sürüklenecek bundan yararlanamayacak.

Ancak gerekli özelliklerin tartışılmasıyla başlayıp belirli uygulama ayrıntılarını atarak projeye katılabilirim, çünkü. bunda bir fayda var, çerçeve diyelim.

Faydası basittir, ilk mesajlarda Alex tarafından dile getirilmiştir. Topluluk, terminal geliştiricilerini MQL platformunu geliştirmeleri için etkileyebilir.

İyileştirmeler için umutlarım (doğrudan programlama arayüzleriyle ilgili):

  1. MQL uygulaması - diğerlerini iptal etmeyen ayrı bir program türü olarak (onTick'i yoktur ve varsayılan sembole erişme yeteneği yoktur - bu geçmişin bir kalıntısıdır, ancak herhangi bir sembol ve ticaretin ticaret ortamını alma yeteneğine sahiptir. , çünkü her şey çoklu para birimidir), uygulama çizelgeye özgü karakterde değil, kendi penceresinde başlatılmalıdır. Böyle bir programı grafiğe sürüklediyseniz, yeni bir pencere açılacaktır. Evet ve sürükleyip bırakmak gerekli değildir - gezginde 2 kez tıklandığında - yeni bir pencere de açılır. Bu, bazı kişilerden terminale başka bir dilde geliştirmeleri için bir API sağlamalarını istemek gibidir. Konuyu geliştirirken, özel bir şekilde derlenen böyle bir programın terminal olmadan çalıştırılabileceği varsayılabilir (ve güvenlik için bu tür derlemeye yalnızca Market üzerinden izin verilir). Kulağa çılgınca geliyor, değil mi?
  2. Ayrı bir dosya ile temsil edilen üçüncü taraf vektör yazı tipleri için destek ve kaynak olarak derleme yeteneği (belgelerde belirtilmiştir, ancak uygulanmamıştır)
  3. Fare tekerleği kaydırma olayını yakalamak
  4. Sağ düğmedeki sistem menüsünü kilitleme. Sağ düğme şu anda işleniyor, ancak işe yaramaz.
  5. Sistem panosuyla çalışarak, kendi metin düzenleme kontrollerinizi (çok satırlı bir düzenleyici dahil) oluşturmak için boşluk ve giriş zaten engellenebilir - iyi.
 

@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.

 
o_O :

@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?

 
o_O :

...

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:

"İki hesap"taki tüm öğelerin özelliklerini değiştirmeniz gerekiyorsa, tüm arabirim öğelerine erişiminiz olan sınıfta (tasarımla ilgili ve tüm öğeler için geçerli olan genel özellikler için) ayrı yöntemler oluşturmanız yeterlidir.

Prensip olarak, planımda bunun nasıl uygulanabileceğini zaten görüyorum. Örneğin, olaylar aracılığıyla. Ancak daha sonra her öğenin olay işleyicisinde bu olayı işlemeniz gerekir (kod şişirilir). İkinci seçenek, genel GUI olaylarının işlendiği veya daha da yüksek olduğu, GUI öğelerine yönelik tüm işaretçilerin depolandığı bir sınıfta özel bir genel yöntem oluşturmaktır. Her ikisi de özel MQL uygulama sınıfının temel sınıflarıdır ve kullanıcının buna doğrudan erişimi olacaktır. (1) bir özellik ve bir değer veya (2) bir özellik, bir değiştirici ve bir değer ayarlamanız gereken MQL'deki (örneğin, ElementSet ) aşırı yüklenmiş ObjectSet yöntemleri gibi bir şey olabilir.

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. )

Neden: