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