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

 
Реter Konow :

))) 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.
Peter Konow'un fotoğrafı.

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:

m_pixels[Y*Width+X] = 0x0000FF; // 0x00FF00 зеленый, - 0xFF0000 - синий, 0x00FFFF - желтый и т.д.

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:

 //+------------------------------------------------------------------+
//|                                                  CleanScreen.mq5 |
//|                        Copyright 2016, MetaQuotes Software Corp. |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+

// Внимание !!! В классе CCanvas массив m_pixels должен быть определен как public
#include <Canvas\Canvas.mqh>

void OnStart ()
  {
   ChartSetInteger ( 0 ,CHART_SHOW, false ); // очищаем экран от всего
   int Width =( int ) ChartGetInteger ( 0 , CHART_WIDTH_IN_PIXELS );   // получаем Ширину экрана
   int Height=( int ) ChartGetInteger ( 0 , CHART_HEIGHT_IN_PIXELS ); // получаем Высоту экрана

   CCanvas C;   // создаем объект Canvas
   if (!C.CreateBitmapLabel( 0 , 0 , "CleanScreen" , 0 , 0 ,Width,Height, COLOR_FORMAT_XRGB_NOALPHA )) // Создаем холст на весь экран
       Print ( "Error creating canvas: " , GetLastError ());

// Теперь что-нибудь нарисуем на этом чистом экране
// например красную точку в центре экрана
   int X=Width/ 2 ;
   int Y=Height/ 2 ;
   C.m_pixels[Y*Width+X]= 0xFF0000 ; // красный
                                   // или нарисуем окружность в центре с радиусом 100 по точкам фиолетового цвета
   int r= 100 ;
   int q=( int ) ceil (r* M_SQRT1_2 );
   int r2=r*r;
   for ( int x= 0 ; x<=q; x++)
     {
       int y=( int ) round ( sqrt (r2-x*x));
      C.m_pixels[(Y+y)*Width+X+x]= 0xFF00FF ;
      C.m_pixels[(Y+y)*Width+X-x]= 0xFF00FF ;
      C.m_pixels[(Y-y)*Width+X+x]= 0xFF00FF ;
      C.m_pixels[(Y-y)*Width+X-x]= 0xFF00FF ;
      C.m_pixels[(Y+x)*Width+X+y]= 0xFF00FF ;
      C.m_pixels[(Y+x)*Width+X-y]= 0xFF00FF ;
      C.m_pixels[(Y-x)*Width+X+y]= 0xFF00FF ;
      C.m_pixels[(Y-x)*Width+X-y]= 0xFF00FF ;
     }
// конечно же можно окружность построить проще :) - через встроенную функцию класса CCanvas:
   C.Circle(X,Y,r+ 20 , 0xFFFF00 ); // желтого цвета
   C.Update(); // Теперь выводим это на экран
  }

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:


Peter Konow'un fotoğrafı.

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?

Renk, GButton sınıfı içinde ayarlanır ve iki rengi karıştırmak ve bir renkten diğerine akacak bir dizi renk oluşturmak için iki işlev bile vardır, yani. sadece gradyan için. Sadece bir gradyan kavramını tanımlamak gereklidir. Anladığım kadarıyla, bir degrade (veya degrade dolgu), bir rengin diğerine yumuşak bir akışıdır. Örneğinizde degrade yok, sadece 4 renk var. Örneğimde, GButton sınıfı içinde, bir renkten bu rengin farklı parlaklıkta 4 ek rengi daha oluşturulur ve degrade dolgu için bir renk dizisi oluşturulur. Bu sadece sınıfın son kullanıcısı için hayatı basitleştirmek amacıyla yapılır. Bu çiçeklerin oluşumuyla neden uğraşsın ki?
Senin örneğine benzer bir şey çizmek senin ödevin, Piotr :)) Dersleri anlamaya başlayalım, yani OOP.
İyi şanlar!
 
Nikolai Semko :

İyi şanlar!

Tamam Nikolay. Teşekkürler ve size de iyi şanslar!
 
Nikolai Semko :

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

 
Реter Konow :

...

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. )
 
Anatoli Kazharski :

Bu kişi muhtemelen hayal gücünüzde şiddetle savaştığınız yel değirmenlerinden biridir. )
İyi! Troller kaçıyor...
 
Реter Konow :
İyi! Troller kaçıyor...
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. )
 
Реter Konow :

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.

 
Anatoli Kazharski :
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.

Bu konuda hemfikir olmamak mümkün değil.
 
Реter Konow :

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