//+------------------------------------------------------------------+//| CleanScreen.mq5 |//| Copyright 2016, MetaQuotes Software Corp. |//| https://www.mql5.com |//+------------------------------------------------------------------+// Внимание !!! В классе CCanvas массив m_pixels должен быть определен как public#include <Canvas\Canvas.mqh>
voidOnStart()
{
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; // создаем объект Canvasif(!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(); // Теперь выводим это на экран
}
)))さて、なぜこのトピックを立ち上げたかというと) これからOOPを勉強します。
それが、実践から理論へという、あなたの方法の利点です。私もそのようにしたことがあります。私は以前、OOPパラダイムが世に存在しない頃にプログラミングを始めたので、直感的に長い間抵抗していたのです。でも今は、これこそがプログラミングにおける最も価値のある発明だと理解しています。そして、もしAOPがまだ発明されていなかったら、自分で発明していたかもしれないと思うこともあります :)) 。
OOPのすばらしさを知り、その可能性を知ったとき、ピーターさんはきっと喜ぶでしょう。断言します :)) 。そして、特にプログラミング経験のあるあなたにとって、OOPには複雑で絡み合うものはありません。そして、あなたの場合、Metakvotのドキュメントが あれば十分とさえ思えるのです。世の中にはたくさんの文献があります。
しかし、ニコライ、私はまだ私が尋ねたことを理解していない - CCcanvasクラスでフレームのグラデーション線に特定の色を設定する可能性がありますか？あなたの例を見ると、「あるある」と思うかもしれませんが......。その場合、私の例と似たようなものを描けるでしょうか？
OK、OK。このスレッドの主題ではありませんが、知識のあるプログラマにとっては当たり前のことでも、初めてCanvasに出会うプログラマにとっては当たり前でないことを明らかにしていこうと思います。
では、Canvasとは何か。英語ではキャンバスと訳される。それは、単にウィンドウ内の画面の任意の領域を、そのウィンドウに貼り付けることです。主な特徴は、そのサイズ（幅と高さ）です。そして、実際には、サイズWidth*Heightのuint型（4バイト）の点の1次元 配列である。CCanvas クラスの実装では、この配列は m_pixels と呼ばれ、デフォルトでは privat（クラス内部でのみアクセス可能）ですが、個人的にはデータ配列を直接操作したいので、常に public（クラス内部だけでなく、ユーザーアプリケーションからもアクセス可能）にしています。このキャンバス上の各点は、カラータイプ（これもuintのように4バイト、1バイト予約）の任意の値を取ることができ、これはRGBの任意の色の点を意味する。各色（赤、緑、青）は1バイト（256値）に対応するので、RGBの色は全部で256*256*256=16,777,216色になります。
X,Y 座標に赤い点を置くには、X は 0 から (Width-1) の値を取り、Y は 0 から (Height-1) の値を取る、配列 m_pixels の (Y*Width+X) 番号のセルに赤い値を割り当てるだけです。
m_pixels[Y*Width+X]=clrRed;または同じものであること。
That's ALL!!!
CCanvas クラスの組み込み関数も使えなくなりました（もちろん、便利なものがたくさんあるので、これは馬鹿げています）。画面のどこにでも、どんな色でも、点を置くことができれば-ボタン、グラフィックス、独自のGDIを作成するなど、欲しいものを神して描くのです。
そして、もしkanvasが遅いと思っている人がいたら、それは間違いです。Kanvasは信じられないほど高速で、開発チームのおかげです。C++で書かれたDllライブラリも使って、何度もkanvasの描画速度をテストしています。昨年のアップデート後、MT5上のキャンバスは、Visual StudioでC++で書いた場合とほぼ同等の速度で動作するようになりました。10〜15％程度しか遅くならない。そして忘れてはならないのは、WindowsはC++で書かれていて、すべてCanvasであるということです。これがMQL5を搭載したMT5の良さであり、約束事なのです!!!このスレッドで何人かが書いているように、JavaもC#もこのようなスピードを誇ることはできないでしょう。
最近、開発者はグラフのレンダリングを無効にするための新しいプロパティ CHART_SHOW を導入しました。
スクリプトの例で実演してみます。
このスクリプトの動作。
画面は消去されますが、相場へのアクセスは可能です。この真っ白なキャンバスを利用して、グラデーションを使ったこのような独自のチャートインターフェイスを作ることができます。
しかし、ニコライ、私はまだ私が尋ねたことを理解していない - CCcanvas クラスに、フレームのグラデーション ラインに特定の色を設定するオプションがありますか？あなたの例を見ると、あるような気がしますが......。その場合、私の例と似たようなものを描けるでしょうか？
あなたの例と同じようなものを描いてください - 宿題です、ピーター :))さあ、クラスを理解することから始めましょう、それ故にOOPです。
がんばってください。
がんばってください。
よし、ニコライ。ありがとうございます！そして、頑張ってください。
ニコライさん、昨日の有益な投稿に返信したかったのですが、考えがまとまりませんでした。今、自分の考えをまとめてみて、頭で考えるのではなく、心で書かないと何も説明できないことに気がつきました。もちろん、オフトピックになるので、モデレーターは削除するでしょうが、それでも......。
OOPについて書かれていることは、感動的です。もう、本気でマスターするつもりで勉強に取りかかっています。しかし、それを習得する過程で、"近道があるのに、なぜ遠回りするのか？"というカテゴリーの質問を常に受けるようになったのです。簡単で簡潔で明快な問題解決の方法を常に目にし、「いや、OOPではこれは解決策にならない」と言われているような気がしたのです。正式な、正式な、高貴なやり方でやらなければならない。"それに対して私は、「しかし、どうしてそうなるのだろう？そういう存在は必要ないんです。なぜ、コードに追加する必要があるのでしょうか？余計なお世話なんです。コードを縮めたい"そして、「いや、プロじゃないから」と。それは悪いコードだ"
私は、OOPが自分にとってどのような利点があるのかを考えようと、いろいろと議論していました。私は、「OOPを使わなくても、完璧に簡単にタスクを解決できるのなら、なぜ使う必要があるのだろう」と考えていました。なぜ、私にとっては単純で明快なことを、さらに複雑にしなければならないのか。どうやって、どこに、なぜ、必要のないものをコードに入れなければならないのか」ということです。そこで、「私は何でも自分でやるし、得意だから、OOPは必要ない」と判断しました。自分で何でもやって、何も突っ込まず、しかも最も効果的な解決策を探し求めていると、「なぜ、それ以外なんだ」という疑問が自然に湧いてきます。OOPは、プログラムに快適さと秩序を与えてくれるように思います。はい、そうです。でも、私にも順番があるんです。自分なりの構造私自身の存在。自分なりのルールでは、なぜ拒否する必要があるのでしょうか？
私たちの体が異質な組織を拒絶するように、私は異質な思考の産物と「融合」することができなかったのです。どこもかしこも、拒絶されているように感じた。私にとっては、PLOは誰かの思想によって作られた秩序であり、私の効力テストに合格するものではありませんでした。このテストが決め手となりました。OOPを使うと、自分のやり方ですべての問題を解決するよりも、弱いプログラマーになってしまうことに気づいたのです。私の「プログラミングの強み」は、わかりやすいロシア語で書くこと、「カーネル」と呼ぶグラフィックオブジェクト用の共有グローバルメモリを使うこと、このカーネルと連動する大規模で複雑な機構を作ることです。これが私のやり方です。
この手法で誰かに負けるまで、私はOOPプログラミングをしません。私がやっていることを、もっと効率的にやってくれるまで。
私がkanvasについて質問したのは、なぜ自分の仕組みの方が事実上効果的であることが判明したのか、その理由を知りたかったからです。理論でもなく、コードの美しさでもなく、実践の場である。
とにかく、私にインスピレーションを与え、導いてくれたニコライに感謝します。))
...
この方法で誰かが私を打ち負かすまで、私はOOPプログラミングをしないでしょう。
...
その誰かとは、あなたが想像の中で必死に戦っている風車の一つなのでしょう。)
この人は、あなたが想像の中で必死に戦っている風車のひとつに違いない。)
ほらね！トロールがやってくる...))
私は絶対にOOPが好きではありませんが、少なくとも自己啓発のために、プログラマーを自認するならば、OOPを知り、明確に使いこなせるようにならなければなりません。
しかし、アプリケーションの課題を解決するために使うか使わないかは、あなた次第です。
落ち着け、ピーター。ただの粉砕機です。彼らはただ立っていて、ある 機能を果たしているだけで、あなたを倒そうとはしていないのです。しかし、あなたの想像力の中で、それがどのように可視化されているのか、誰にもわからないのです。どう見ても、とても華やかな印象です。)
アナトリー ミルズであろうとなかろうと、私は戦って勝つのが好きなんです。特に得意なことでは。ライブの対戦、デュエルとか好きなんですけどね...。すべては進化と自然淘汰の一環なのです。だからいいんです...。ルールが公平であればいい。
同じ志を持つ仲間と協力し、共通のプロジェクトに参加し、チームの一員として働くこともまたクールです。そして、想像力はもちろん、現実に取って代わるものであってはなりません。そういうことなら、納得です。
...しかし、少なくとも自己啓発のために、プログラマーを自認するならば、明確に知って、使えるようにしなければならない。
しかし、アプリケーションの問題を解決するために使うかどうかは、あなた次第です。
この手法で誰かに負けるまで、私はOOPプログラミングをしません。私がやっていることを、もっと効率的にやってくれるまで。
私がkanvasについて質問したのは、なぜ自分の仕組みの方が事実上効果的であることが判明したのか、その理由を知りたかったからです。理論やコードの美しさではなく、実践の中で。
いずれにせよ、私にインスピレーションを与え、導いてくれたニコライに感謝します。))
もし、同じような経験と知能を持つ2人のプログラマーが、同じような大きな プロジェクトを作りながら競争しているとしたら。しかし、前者は関数だけを使い、後者は関数とクラスを使っている。2番目は間違いなく勝つでしょう。しかし、繰り返しになりますが、ボリュームのあるプロジェクトであれば、後者の方がバグが少なく、秩序があるため、より早く仕上げることができます。そして、2番目の製品は、より読みやすく、保守しやすく、更新や補足がより簡単にできるようになります。これは私のイミフでもなく、ただの事実の表明です。こてよりもスコップで穴を掘る方が簡単です。関数だけでなく、クラスにも仕組みを実装すれば、より効率的になるはずです。それが私のイメトレです。
そして、Peter、あなたのコードを ざっと見たところ、canvasをフルに使っていることがわかりました（CCanvasクラスではないけれど、気にする人はいないでしょう）。では、なぜキャンバスについての質問があるのか、なぜ私がここでこれらのことを説明しようとするのか。:)).