![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
))) Peki, bu konuyu neden açtım? ) Şimdi OOP çalışacağım.
Bu, yolunuzun avantajıdır - pratikten teoriye. Ben de bu yoldan geçtim. İçgüdülerim uzun süre OOP paradigmasını kabul etmedi, çünkü Doğada yokken programlamaya başladım. Ama şimdi bunun programlamadaki en değerli buluş olduğunu anlıyorum. Ve bazen bana öyle geliyor ki, henüz kimse OOP'yi icat etmemiş olsaydı, o zaman kendim icat ederdim :))
Sen Peter, bundan hoşlanacaksın ve OOP'nin güzelliğini ve ne tür fırsatlar açtığını anladığında sevineceksin. Seni temin ederim :)). Ve OOP'de, özellikle programlama deneyiminizle sizin için karmaşık ve kafa karıştırıcı hiçbir şey yoktur. Ve bana öyle geliyor ki, sizin durumunuzda Metaquotes belgeleri öze inmek için bile yeterli olabilir. Edebiyat denizi.
Ama Nikolai, hala neyi sorduğumu anlamadım - CCcanvas sınıfında sınır degrade çizgileri için belirli bir renk ayarlamak mümkün mü? Örneğinize bakınca, var olduğunu düşünebilirsiniz... Eğer öyleyse, benim örneğime benzer bir şey çizebilir misiniz?
Tamam, tamam. Bu konunun konusu bu olmasa da, bilgili programcılara açık görünen ancak Canvas ile ilk kez karşılaşan programcılara açık olmayan bazı şeyleri açıklığa kavuşturmaya çalışacağım.
Peki Kanvas nedir. İngilizce'den çevrilmiş - tuval. Bu, daha sonra eklendiği pencere içindeki ekranın herhangi bir alanıdır. Başlıca özellikleri boyutudur: Genişlik (Genişlik) ve Yükseklik (Yükseklik). Ve aslında bu, Genişlik*Yükseklik boyutuna sahip uint tipinde (4 bayt) tek boyutlu bir nokta dizisidir. CCanvas sınıfının uygulanmasında, bu diziye m_pixels denir, varsayılan olarak özeldir (yani yalnızca sınıf içinde kullanılabilir), ancak kişisel olarak onu her zaman herkese açık hale getiririm (yalnızca sınıf içinde değil, aynı zamanda kullanıcı uygulamalar), çünkü doğrudan veri dizisiyle çalışmak istiyorum. Bu tuvalin her noktası herhangi bir renk türü değerini alabilir (aynı zamanda uint gibi 4 bayt, bir bayt ayrılmış), bu da herhangi bir RGB renginin noktası anlamına gelir. Her renk (Kırmızı, Yeşil veya Mavi) bir bayta (256 değer) karşılık gelir ve buna göre tüm RGB renklerinden 256 * 256 * 256 = 16 777 216 vardır.
X'in 0'dan (Genişlik-1) ve Y'den (Yükseklik-1)'e kadar değerler alabileceği X,Y koordinatlarına bir nokta koymak için, diyelim ki, kırmızı renk değerini koordinatlara atamanız yeterlidir. m_pixels dizi hücresi (Y * Genişlik+X) :
m_pixels[Y*Width+X]= clrRed ;
veya aynısı nedir:
Hepsi bu!!!
Artık CCanvas sınıfının yerleşik işlevlerini kullanmak zorunda bile değilsiniz (ki bu elbette aptalcadır, çünkü orada birçok yararlı şey vardır). Ekrana herhangi bir yere ve herhangi bir renge bir nokta koyabiliyorsanız - istediğiniz şey Tanrı'sınız, o zaman çizin: düğmeler, grafikler, kendi GDI'nizi oluşturun, vb. vb.
Ve eğer biri tuvalin yavaş çalıştığını düşünüyorsa, o zaman yanılıyor. Canvas inanılmaz derecede çeviktir ve bu, geliştirme ekibinin meziyetidir. Tuvalin çizim hızını ve C++ ile yazılmış Dll kitaplıklarını kullanarak defalarca test ettim. Şimdi, geçen yılki güncellemelerden sonra, MT5 üzerindeki tuval, neredeyse Visual Studio'da C++ ile yazdığınız kadar hızlı çalışıyor. Sadece %10-15 daha yavaş. Ve unutmayın - Windows C++ ile yazılmıştır ve sağlam bir Canvas'tır. MQL5 ile MT5'in güzelliği ve beklentileri bu!!! Bazılarının bu başlıkta yazdığı gibi ne Java ne de C# böyle bir hıza sahip olamaz.
Geliştiricilerin yakın zamanda grafiğin görüntülenmesini devre dışı bırakmak için yeni bir CHART_SHOW özelliği sunmuş olmaları boşuna değil.
Bunu örnek bir komut dosyasıyla göstereceğim:
Bu komut dosyası nasıl çalışır:
Ekran temizlenir, ancak alıntılara erişim kalır ve bu boş tuvali, örneğin bir degradeyle kendi grafik arabirimimizi yapmak için kullanabiliriz:
Ama Nikolai, hala neyi sorduğumu anlamadım - CCcanvas sınıfında sınır degrade çizgileri için belirli bir renk ayarlamak mümkün mü? Örneğinize bakınca, var olduğunu düşünebilirsiniz... Eğer öyleyse, benim örneğime benzer bir şey çizebilir misiniz?
Senin örneğine benzer bir şey çizmek senin ödevin, Piotr :)) Dersleri anlamaya başlayalım, yani OOP.
İyi şanlar!
İyi şanlar!
Tamam Nikolay. Teşekkürler ve size de iyi şanslar!
Nikolay, dün bilgilendirici yazınıza cevap vermek istedim ama aklıma toplayamadım. Şimdi kendimi bir araya getirdim ve akıldan değil, kalpten yazmanız gerektiğini anladım, aksi takdirde hiçbir şey açıklamayacağım. Tabii konu dışı çıkacak ve moderatörler muhtemelen silecek ama yine de ..
OOP hakkında yazdıklarınız ilham verici. Onun çalışmasına ciddi anlamda hakim olma niyetiyle başladım bile. Ancak, çalışma sürecinde, "kısa bir yol varken neden uzun bir yol gideyim?" kategorisindeki sorularla sürekli bunaldım. Sorunları çözmenin kolay, özlü ve net yollarını sürekli gördüm ve sanki bana diyorlardı ki, - "Hayır! OOP'de bu çözülmez. Her şeyi formda, terbiyeli ve asil bir şekilde yapmanız gerekir." . Cevap olarak kendi kendime sordum - "Ama nasıl? Bu varlıklara ihtiyacım yok. Bunları neden koda ekleyeyim? Gereksizler. Kodu sıkıştırmak istiyorum." Ve cevabım şuydu: "Hayır! Bu profesyonel değil. Bu kötü kod.".
OOP konusunda kendimle çok tartıştım, benim için avantajlarının ne olduğunu anlamaya çalıştım. "Problemleri OOP olmadan güzel ve kolay bir şekilde çözüyorsam neden kullanayım? Benim için basit ve anlaşılır olan şeyleri neden daha da karmaşık hale getireyim? Koduma ihtiyacım olmayan şeyi nasıl, nerede ve neden koyayım?" diye düşündüm. ? ". Sonra OOP'ye ihtiyacım olmadığına karar verdim çünkü her şeyi kendim yapıyorum ve çok iyi yapıyorum. Her şeyi kendiniz yaptığınızda ve hiçbir şeyi bağlamayı beklemediğinizde ve dahası, en etkili çözümleri arayıp bulduğunuzda, doğal bir soru ortaya çıkar - "neden başka bir şey?". OOP, programa kolaylık ve düzen sağlıyor gibi görünüyor. Evet öyle. Ama benim kendi düzenim var. Kendi yapısı. Senin özlerin. Kendi kuralları. Neden reddetmeliyim?
Tıpkı vücudumuzun yabancı dokuyu reddetmesi gibi, ben de başka birinin düşüncesinin ürünü ile "büyüyemezdim". Her yerde ve her şeyde reddedildiğimi hissettim. OOP benim için başka birinin düşüncesiyle oluşturulmuş bir emirdi ve verimlilik testimi geçemedi. Bu test benim için belirleyici faktör oldu. OOP kullanırsam, kendi yoluma gidip tüm sorunları kendim çözmekten daha zayıf bir programcı olacağımı fark ettim. Benim "yazılım gücüm", anlayabildiğim Rusça yazmam, "çekirdek" dediğim grafik nesneler için ortak bir küresel bellek kullanmam ve bu çekirdekle çalışan büyük ve karmaşık mekanizmalar oluşturmamdır. Benim yaklaşımım burada yatıyor.
Birisi beni bu yaklaşımla yenene kadar OOP programlamayacağım. Benim onunla yaptığımı yapana kadar, ama daha da verimli.
Tuvali sordum çünkü aslında mekanizmamın neden daha verimli olduğunu anlamak istedim. Teorilerde değil, kodun güzelliğinde değil, pratikte.
Her durumda, ilham verici ve yol gösterici desteğiniz için teşekkür ederim Nikolai. ))
...
Birisi beni bu yaklaşımla yenene kadar OOP programlamayacağım.
...
Bu kişi muhtemelen hayal gücünüzde şiddetle savaştığınız yel değirmenlerinden biridir. )
Bu kişi muhtemelen hayal gücünüzde şiddetle savaştığınız yel değirmenlerinden biridir. )
İyi! Troller kaçıyor...
Ben kesinlikle bir OOP hayranı değilim, ancak kendinizi bir programcı olarak görüyorsanız, en azından kendi kendine eğitim adına, bunu açıkça bilmeli ve kullanabilmelisiniz.
Ancak uyguladığınız sorunları çözmek ya da çözmemek kesinlikle sizin işiniz.
Sakin ol Peter. Bunlar sadece öğütücüler. Sadece dururlar, belirli bir işlevi yerine getirirler ve sizi yenmeye çalışmazlar. Gerçi, zengin hayal gücünüzde nasıl görselleştirildiğini kim bilebilir. Görünüşe göre çok etkileyici görünüyor. )
Anatoly, Mills ya da değil, savaşmayı ve kazanmayı severim. Özellikle iyi olduğum şeylerde. Canlı rekabeti, kavgaları vb. severim... Bunların hepsi evrimin ve doğal seçilimin bir parçası. Yani sorun değil... Esas olan, kuralların adil olmasıdır.
Benzer düşünen insanlarla işbirliği yapın, ortak projelere katılın, bir takımda çalışmak da harika. Ve elbette hayal gücü gerçeğin yerini almamalıdır. Demek istediğin buysa, o zaman katılıyorum.
... ancak kendinizi bir programcı olarak görüyorsanız, en azından kendi kendine eğitim adına, bunu bilmeli ve net bir şekilde kullanabilmelisiniz.
Ancak uyguladığınız sorunları çözmek ya da çözmemek kesinlikle sizin işiniz.
Birisi beni bu yaklaşımla yenene kadar OOP programlamayacağım. Benim onunla yaptığımı yapana kadar, ama daha da verimli.
Tuvali sordum çünkü aslında mekanizmamın neden daha verimli olduğunu anlamak istedim. Teorilerde değil, kodun güzelliğinde değil, pratikte.
Her durumda, ilham verici ve yol gösterici desteğiniz için teşekkür ederim Nikolai. ))
Aynı deneyime ve zekaya sahip iki programcı rekabet ederse, benzer büyük projeler yaratır. Ancak ilki yalnızca işlevleri, ikincisi ise işlevleri ve sınıfları kullanır. Galibiyet kesinlikle ikinci olacak. Ancak tekrar ediyorum - bu hacimli bir projeyse, daha hızlı hale getirecek çünkü. daha az hata ve daha fazla düzen olacak. İkinci ürün ise daha okunaklı, bakımı kolay ve daha kolay güncellenen ve doldurulan olacak. Bu benim fikrim bile değil, sadece bir gerçeğin ifadesi. Kürekle çukur kazmak kürekle kazmaktan daha kolaydır. Mekanizmanızı sadece fonksiyonlara değil sınıflara da uygularsanız daha verimli olur. İşte benim IMHO'm.
Ve Peter, kodunuza kısaca baktım ve canvas'ı Might ve main ile kullandığınızı fark ettim (CCanvas sınıfı olmasa da, fark nedir). O zaman neden tuvalle ilgili tüm bu sorular ve neden burada çarmıha gerdim? :)).