dinamik olarak nesneler nasıl oluşturulur? (Bazı OOP şeyler) - sayfa 5

 
Doerk Hilger'in fotoğrafı.

2. Sıfırdan çerçeve.

Burada benzer. Standart kütüphanelerde biraz daha derine inmeye başladığımda, sevmediğim birçok şey buldum. Sadece bunların kötü performansı değil, aynı zamanda esneklik eksikliği ve eksik bir mimari nedeniyle. Örneğin, CWnd ve CObject arasındaki bir sınıfın yanı sıra global bir CMouse sınıfını/nesnesini de özlüyorum, çünkü CWnd nesneleri, çizgilerin yanı sıra grafiğin çocuklarıdır ve böyle bir bağlantı yoktur ve bu tür nesnelerin nihai uygulaması yoktur. tamamen yukarıda anlattığım gibi. Ve tüm bu tür grafik nesnelerini tutan, hepsini tek bir komutla göstermeyi/gizlemeyi, yok etmeyi mümkün kılan bir ana nesne yoktur. CCanvas, aynı şey, güzel bir sınıf ama CWnd'den miras kalan bitmap'lere dayalı etkileşimli nesneler oluşturmama izin veren CWnd ile uygulama nerede? Ve benzeri.




Küresel bir CMouse'un rolü nedir? Fare yönetimine kolay erişim sağlamak için son kullanıcıya yalnızca bağımsız bir sınıf olarak mı hizmet ediyor? çerçeve ile ilişkisi nasıldır?
CWnd ve CObject arasındaki sınıf hakkında, onları neden gerekli bulduğunuza dair açıklamanızı takip etmiyorum. CWnd nesneleri, çizgilerin yanı sıra grafiğin alt öğesidir - Bundaki sorunu anlamıyorum ve neden bağlantı yok?
Ayrıca, yukarıda açıkladığınız gibi bu tür nesnelerin nihai bir uygulamasının olmadığını mı söylüyorsunuz? (nerede tarif ettin?)

 

Global bir fare nesnesinin fırsatı, en azından benim GUI'mde, her türlü bilgiyle ilgilenen her sınıf için erişilebilir olan fare hakkındaki herhangi bir bilgiyi (konum, pres pozisyonu, pozisyonun fiyatı vb.) kaydetmektir. Ayrıca fare nesnesi, örneğin sürüklerken, farenin özel kullanımına ilişkin bilgileri tutar. Bu, bir şey sürüklenirken veya tıklanmak üzereyken vb. CPU zamanından tasarruf sağlar.

Son fakat en az değil: Fare olayı olmadığı için EA'larda kullanıldığında standart kitaplığın hiçbir şey strateji test cihazında çalışmaz. Strateji test cihazında fare desteğini uygulamak istiyorsanız, böyle bir fare sınıfı için de minnettar olacaksınız, çünkü sınıf fare hareketleri hakkındaki bilgilerin nereden geldiği ile ilgilenmez, ancak bilgiye ihtiyaç duyan nesneler hala nerede olduklarını bilirler. aramak zorunda.

---

Eksik olan sadece CWnd ve CObject arasındaki sınıf değil, aslında daha çok piksel tabanlı nesneleri ve ayrıca zaman/fiyat tabanlı nesneleri tutan eksik ana nesne/konteyner. Sizin de bahsettiğiniz gibi, hepsi grafiğin nesneleridir, bu nedenle mantıksal master, grafiği temsil eden ve tüm nesneleri tutan bir nesne olmalıdır. Ve bunu gerçekleştirmek için CWnd ve CObject arasında bir sınıf olmalıdır.

Bu fikrin arka planı sadece mantık değil, aynı zamanda bir performans meselesidir. Benim durumumda, grafik bir şekilde değiştiğinde, ana nesne bunu algılar, satır kapsayıcıları, CWnd kapsayıcıları olabilen tüm içerilen nesneleri ve ayrıca bu türlerden herhangi birinden herhangi bir tek nesneyi döngüler ve herhangi bir nesneyi "bilgilendirir". bundan haberdar olmak istiyor. Bu, kodun tam olarak bir noktasında tek bir döngü olduğu anlamına gelir ve kapsayıcılar ve alt kapsayıcılar ile kullanım nedeniyle bu son derece verimlidir.

Ayrıca bu master'ı tüm nesneleri bir kerede dondurmak ve herhangi bir fiziksel güncellemeyi yalnızca bir kod satırıyla önlemek için kullanıyorum. Performans farkı çok ciddi. Örnek: EA'm için ihtiyacım olan tüm görsel nesneleri oluşturduğumda ve bazı durumlarda tezler 1000'den fazla olduğunda, bu ana nesneyi önceden dondurur, diğer nesneleri yaratır ve daha sonra onu "çözdürürüm", bu da tek bir fiziksel güncellemeyle sonuçlanır. çizelge. Donmadan, bu işlem bir dakika sürebilir. Donma ile, 2 saniyeden az.

GUI'yi kendim oluşturmaya başlamadan önce, gerçekten standart lib'lerle denedim. Daha sonra en azından bazı kısımları saklamaya çalıştım. Ama sorun şu ki, eksik bir uygulama ve bir tür mimari nedeniyle aklımdaki şeyi gerçekleştirmenin imkansız olmasıydı ... LetsMakeSomethingThatWorksSomehowForWeDontKnow. Görsel performansa net bir hiyerarşi ile ulaşılır, ancak standart kütüphaneler bir şekilde anarşisttir.

Her neyse, bunu fark eden ilk kişi ben değilim. Alain'in daha önce de belirttiği gibi, bunun gerçekten yardımcı olup olmadığından emin değilim, çünkü çok teorik. Sadece MQL'ye dayanmayan tüm bu şeylerle ilgili deneyimlerimden bahsedebilirim, ancak görüşüm yine de sadece benim görüşüm ve elbette yasa değil.

 
İlk olarak, bunun çok teorik olduğuna katılmıyorum. Bence çok anlayışlı. Çerçeve oluşturmakla ilgilenmeyen ve bunları bir arayüz paneli oluşturmak için kullanması gereken insanlar için teorik olduğunu kabul edebilirim.

Ancak ikinci tür için burada tartışılan düşünce tarzı ve mülahazalar çok değerli ve çok pratiktir. Elbette bir makale daha iyi olurdu, ama yine de.
İnsanların sadece bu konuyu okuduktan sonra çerçeveler inşa edeceklerini sanmıyorum, ancak yine de iyi bilgi ve içgörü parçaları var, bu zaten kamuya açık MQL çerçeveleri inşa etmiş insanlar için bile eksik görünüyor.

Bu nedenle, fare ve test cihazı için, sizi doğru anladıysam, sizi takip edersem, kullanıcı girişi yerine farenizi çağırmak için ::OnTester() kullanın.

Tekrar teşekkürler, Doerk.
 
Doerk Hilger :

Global bir fare nesnesinin fırsatı, en azından benim GUI'mde, her türlü bilgiyle ilgilenen her sınıf için erişilebilir olan fare hakkındaki herhangi bir bilgiyi (konum, pres pozisyonu, pozisyonun fiyatı vb.) kaydetmektir. Ayrıca fare nesnesi, örneğin sürüklerken, farenin özel kullanımına ilişkin bilgileri tutar. Bu, bir şey sürüklenirken veya tıklanmak üzereyken vb. CPU zamanından tasarruf sağlar.

Son fakat en az değil: Fare olayı olmadığı için EA'larda kullanıldığında standart kitaplığın hiçbir şey strateji test cihazında çalışmaz. Strateji test cihazında fare desteğini uygulamak istiyorsanız, böyle bir fare sınıfı için de minnettar olacaksınız, çünkü sınıf fare hareketleri hakkındaki bilgilerin nereden geldiği ile ilgilenmez, ancak bilgiye ihtiyaç duyan nesneler hala nerede olduklarını bilirler. aramak zorunda.

Genel farenin şimdi bir nesneye tıklamayı fark ettiğini, açıklamanıza göre, nesnenin kendisinin fare sınıfındaki bu bilgilere bakması gerektiğini varsayalım - farenin nesneyi (olay üzerinde hareket ederek) nesneye bildirmesi gerekmez mi? nesne? Varsa, CPU zamanı nereye kaydedilir? Olmazsa, o zaman nesne nasıl bir fare olayını kaçırmaz, örneğin bir butona tıkladım ve sonra bir açılan kutuya tıkladım, farem butona tıklandığını bildirmedi ve şimdi fare en son tıklanan nesneye sahip birleşik giriş kutusu olarak. Bu nedenle, farenin bir nesnenin tıklanması olayının üzerinden geçmesi gerekir. Yani MT5'ten kontrol sınıfına gelen object clicked olayı yerine mouse'a geliyor ve daha sonra kontrole iletiyor, CPU'nun tasarrufu nerede?

Yoksa bir şey mi kaçırıyorum?
 

Mouse nesnesi bir nesnenin üzerindeyse veya şu anda bir nesne tarafından kullanılıyorsa kendisine bakmaz, bu nesnelerin kendileri tarafından yapılır. Ancak fare nesnesi, bu tür bilgilerin saklanabileceği merkezi "yer"dir.

Standart kontrol sınıfları böyle çalışır, her fare hareketinde tüm nesneler, bu hareketin onlarla bir ilgisi olup olmadığını anlamak için döngüye alınır, bu, görev yöneticisini başlattığınızda kolayca görülebilen ve sadece hareket ettiğinizde kolayca görülebilen çok fazla CPU zamanı alır. EA veya Gösterge yüklendiğinde ve bir CDialog nesnesi EA veya göstergenin bir parçası olduğunda fare. İletişim kutusu ne kadar karmaşıksa, CPU kullanımı o kadar yüksek olur.

GUI'mde, global bir fare nesnesinin varlığı ile bu farklı yapılır. 10000 nesneye sahip olabilirsiniz ve fare hareket ettirildiğinde CPU kullanımı hiç artmaz. Bu şekilde yapılır, ancak fare düğmesi belirli bir nesnenin üzerine düşer düşmez, bu belirli nesne fare nesnesine odağa sahip olduğunu bildirir ve fare bu düğme aşağı olayından sonra hareket eder etmez, başka hiçbir şey olmaz. nesnenin bununla ilgilenmesi gerekir ve farenin daha fazla hareketi / herhangi bir fare hareketi olayı, işaretçisi kullanılarak doğrudan odağı olan - her zaman özel olan - nesneye yönlendirilir.

Ve tüm grafik nesnelerinin zaman/fiyat temelli (eğilim çizgileri vb.) veya piksel koordinat tabanlı (paneller vb.) fark etmeksizin ortak bir temel sınıfa sahip olması nedeniyle, tüm bu nesneler ortak bir aşırı yüklenmiş küme kullanabilir. Bunu işlemek için işlevler. CWnd ile CObject arasında bir sınıf eksik olduğundan da bahsetmiş olmamın bir nedeni de bu çünkü aradaki bu taban sınıf, zaman/fiyat bazlı nesneler tarafından da kullanılan taban sınıfla aynı ve ancak bu sayede etkili iletişim ve Bu tür olayları etkili bir şekilde ele almak.

 
yani aslında, fare hareketlerini dinlemeyi bırakırsınız (doğrudan bir nesne tıklamasını takip etmedikçe) ve sadece fare tıklaması ve fare sürüklemesine dikkat edersiniz. Fare tıklamasına gelince, standart lib ile aynı şekilde yapılır, nesne tıklamayı algılar, ancak daha sonra sürüklemeye hazırlanmak ister, böylece muhtemelen konumunu koruyan ve daha fazla sürüklemenin nesneyi geri çağırdığını fareye bildirir. Fare sürüklemeden düğmeyi kaldırırsa, nesne işaretçisini silerek tıklanan nesneye odaklanmayı durdurur. Böylece nesneler tıklamaları ve fare sürüklemeleri dinler.
Yani, bir nesneye tıklanmadan hemen önce fare hareketlerinin aslında önemli olmadığı için görmezden gelindiği ortaya çıkıyor?
 

Evet.

Yine de, tıklanıp tıklanmasa da, daha iyi CPU performansıyla ve nesne adlarını kullanmadan herhangi bir hareketi yakalama seçeneğim var, ancak buradaki soru bu değildi.

 
Evet, şimdi iletmeye çalıştığınız resmi görebiliyorum ve elbette, nesneleri döngüye sokmadan fare hareketlerini bizzat fare tarafından dinlemenin yolları var. Ve hatta dinleyici olarak kaydolurken kullanılan işaretçileri ile odakta olduklarında nesnelere bildirimde bulunabilir.
Neden: