キャンバスがカッコいい! - ページ 22 1...151617181920212223242526272829...93 新しいコメント Реter Konow 2019.02.16 16:39 #211 Nikolai Semko:ピーターさん、6色のマルチグラデーションを実装していることに注目してください。 ここでpは0から1まで変化する。 uint Grad(double p) { static uint Col[6]={0xFFFF0000,0xFFFF00FF,0xFF0000FF,0xFF00FFFF,0xFF00FF00,0xFFFFFF00}; p=p*5; int n=(int)p; if(n==5) return Col[5]; double k=1-p+(int)p; argb c1,c2; c1.clr=Col[n]; c2.clr=Col[n+1]; return ARGB(255,c2.c[0]+uchar(k*((int)c1.c[0]-(int)c2.c[0])+0.5), c2.c[1]+uchar(k*((int)c1.c[1]-(int)c2.c[1])+0.5), c2.c[2]+uchar(k*((int)c1.c[2]-(int)c2.c[2])+0.5)); } ZS でも、一番外側の色にはひとつ問題があって、まだ修正できていないんです。とてもオリジナルです。) p は任意のユーザー番号なのか、それとも何らかのパラメータに紐付いているのか？ これは何のため？ p=p*5; 正しい番号を一度に送信することができます。 この行の後、pは 初期値に戻りません。 これです。 double k=1-p+(int)p; を書くことができます。 double k=1-p+n; の代わりに使ってみてはどうでしょう。 int n=(int)p; int n=MathRound(p); ? ARGB機能はCCanvasの標準機能ですか、それともあなたの機能ですか？ Nikolai Semko 2019.02.16 19:37 #212 Nikolai Semko: しかし、最外周の色にはまだ修正されていない不具合があります。修正しました。 uint Grad(double p) { static uint Col[6]={0xFF0000FF,0xFFFF00FF,0xFFFF0000,0xFFFFFF00,0xFF00FF00,0xFF00FFFF}; if(p>0.9999) return Col[5]; if(p<0.0001) return Col[0]; p=p*5; int n=(int)p; double k=p-n; argb c1,c2; c1.clr=Col[n]; c2.clr=Col[n+1]; return ARGB(255,c1.c[2]+uchar(k*(c2.c[2]-c1.c[2])+0.5), c1.c[1]+uchar(k*(c2.c[1]-c1.c[1])+0.5), c1.c[0]+uchar(k*(c2.c[0]-c1.c[0])+0.5)); } 上記のコードは修正されています。 Nikolai Semko 2019.02.16 19:47 #213 Реter Konow:ARGB機能はCCanvasの内製機能ですか、それともあなたのものですか？ARGBはCCanvasからの定義です。調べるには、名前の上でマウスポインターをクリックし、Alt+Gを押す ReTagコノウ。これは何のため？5は色数-1 Nikolai Semko 2019.02.16 21:21 #214 Реter Konow:の代わりに使ってみてはどうでしょうか？ ダブルが必要ないときは、こちらの方が断然速いので気に入っています。 Реter Konow 2019.02.16 21:25 #215 Nikolai Semko:ARGBはCCanvasからの定義です。調べるには、マウスポインターを名前の上に置いて、Alt+Gを押してください。 5は色数-1オッケーです。批判しているのではなく、ただ聞いているだけです。色彩を扱うのが得意なんですね。 Nikolai Semko 2019.02.16 21:29 #216 Реter Konow:色使いがうまいですね。 ただの趣味です :) Nikolai Semko 2019.02.17 15:20 #217 Artyom Trishkin:私もそう思います。しかし、それとは異なるニーズを持つユーザーのカテゴリーが存在します。 また、kanvasインジケーターの戻り値が512を超えた場合はどうなるのでしょうか？この場合、バッファは役に立ちません。そしてユーザーは、自分のプログラムにある指標からデータを受け取りたいだけなのです。そして、彼らはエキスパート-アドバイザーの本体にそれらを埋め込むことを望んでいない（私はフクロウを惜しまない - それは...でガラガラなしで飛ぶことができます）。そして、目に見えるバーだけでなく、要求されたあらゆるバーのデータを受け取りたいと考えています。そして、これは正当なことです。そして、それは怠惰や何でも簡単に手に入れたいという願望だけでなく、TSの要求によって正当化される。 ニコライ・セムコプログラマーでない大多数のユーザーについて言えば、フクロウかインジケーターのどちらかが必要です。フクロウにインジケーターは必要ないそうです。 私は考えるための情報を提供しただけで、何も押し付けているわけではありません。何が便利で何が不便かは、プログラマーが自分で決めればいいのです。しかし、個人的にはiCustom関数を自分のEAで使うことはないと思っています。 もしかしたら、ちょっと違うかもしれませんね。 このようなキャンバスバッファレスインジケーターをマーケットから購入またはダウンロードしたユーザーは、そのデータを自分のEAで使用したいと考えるのは、非常に論理的なことです。 それなら、この指標の製作者が特別に作った構造体を、リソースを通して読み取るというやり取りが最も合理的だと思います。 プログラマは、この構造体がリソースに最新に保たれるように、自分のkanoval bufferless indicatorで注意し、この構造体がユーザイベントを使用して、または各ティック（タイマを使用するのは妥当ではないと思います）の到来時に読み取られるincluファイルをユーザに提供する必要があります。 そして、ユーザーは1行のコード#include...を入れるだけでよいのです。とすると、この構造は常に指標の実データで利用できることになる。 この構造体は、便利な名前の変数や異なる型のデータ配列（古典的なインジケータのバッファのようにダブル型だけではありません）を含むことができるので、iCustomの 古典的な使用よりも 便利なのはお分かりでしょう。 MQのリソースはインジケータのバッファと同じように実装されているはずですが。 Реter Konow 2019.02.17 15:35 #218 Nikolai Semko: ちょっと違うかな。 このようなCanvaインジケータをマーケットから購入またはダウンロードしたユーザーは、そのデータを自分のEAで使いたいと考えるのは、非常に論理的なことです。 この場合、最も合理的なのは、この指標の製作者が特別に作成した構造体を介して交換し、それをリソースで読み取ることだろう。 プログラマは、この構造体がリソース内で最新の状態に保たれるよう配慮し、ユーザイベントを使用してこの構造体を読み込むインクルファイルをユーザに提供する必要があります。 そして、ユーザーは1行のコード#include...を入れるだけでよいのです。であり、この構造は常に指標の実データで利用できることになる。 iCustomの 古典的な使い方よりもさらに便利だと思います。なぜなら、便利な名前の変数やデータ配列を含むことができ、ユーザーはバッファ番号の意味を気にする必要がなく、プログラムにたった1行のコードを含めるだけでインジケータデータに完全に便利にアクセスできるようになるからです。 MQのリソースはインジケータ・バッファと同じように実装されていると思うのですが。リソースを通じてデータを転送する仕組み自体は、極めてシンプルだ。それよりも、2つのプログラム間の「コミュニケーション」の方法が問題なのです。一方のプログラムは書き込み、もう一方のプログラムは読み出しを行う。したがって、リソースにデータ（インジケータ）を書き込むプログラムは、指定されたメッセージフォーマットを遵守しなければならず、読み込むプログラムはこのフォーマットを「知って」いなければならない。そうすれば、プログラム間のコミュニケーションは普遍的かつ効率的になります。 Nikolai Semko 2019.02.17 15:39 #219 Реter Konow:リソースを通じてデータを転送する仕組み自体は、極めてシンプルだ。それよりも、2つのプログラム間の「コミュニケーション」の方法の方が重要です。一方のプログラムは書き込み、もう一方は読み出しを行う。従って、リソースにデータ（インジケータ）を書き込むプログラムはメッセージのフォーマットを守らなければならず、読み込むプログラムはこのフォーマットを「知って」いなければならない。そうすれば、コミュニケーションは普遍的で応用が効くようになります。もちろん、そうなります。何しろ、受信と送信の部分は、インジケーターそのものを設計した唯一の開発者が行っているのですから。 リソースを介して共有する仕組みは、それほど単純なものではありません。一定のスキルが必要です。それこそ、より高度なプログラマーの特権になりますから、この方法の長所だと思います。 ZS Peter 1ヵ月前は、極めてシンプルで必要なことだと思えなかったんですね。私のメッセージを聞いて、理解してくれてうれしいです。:)) Реter Konow 2019.02.17 15:46 #220 Nikolai Semko:まあ、当然そうなりますよね。何しろ、受信部と送信部は、このインジケーターを自ら開発したたった一人の開発者が作っているのですから。資源を介した交換の仕組みは、それほど単純なものではありません。一定のスキルが必要です。それこそ、より高度なプログラマーの特権になりますから、この方法の長所だと思います。ZS Peter 1ヵ月前は、極めてシンプルで必要なことだと思えなかったんですね。私のメッセージを聞いて、理解してくれてうれしいです。:))ニコライ リソースは、プログラム間のデータ交換に 非常に有効な手段であることがわかったし、その利用は、君が教えてくれたユニオンに基づいている（バシリイもそうだ）。だから、お二人に感謝します）。 データをリソースに転送し、そこから読み出すという仕組み自体は簡単なのですが、普遍性を追求するとメッセージのフォーマットが厄介なことになります。ある特定の指標について問題を解決すれば、すべてがシンプルになります。 1...151617181920212223242526272829...93 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ピーターさん、6色のマルチグラデーションを実装していることに注目してください。
ここでpは0から1まで変化する。
ZS でも、一番外側の色にはひとつ問題があって、まだ修正できていないんです。
とてもオリジナルです。) p は任意のユーザー番号なのか、それとも何らかのパラメータに紐付いているのか？
これは何のため？
p=p*5;正しい番号を一度に送信することができます。 この行の後、pは 初期値に戻りません。
これです。
を書くことができます。
の代わりに使ってみてはどうでしょう。
int n=MathRound(p);?
ARGB機能はCCanvasの標準機能ですか、それともあなたの機能ですか？
しかし、最外周の色にはまだ修正されていない不具合があります。
修正しました。
上記のコードは修正されています。
ARGB機能はCCanvasの内製機能ですか、それともあなたのものですか？
ARGBはCCanvasからの定義です。調べるには、名前の上でマウスポインターをクリックし、Alt+Gを押す
これは何のため？
5は色数-1
の代わりに使ってみてはどうでしょうか？
ARGBはCCanvasからの定義です。調べるには、マウスポインターを名前の上に置いて、Alt+Gを押してください。
5は色数-1
オッケーです。批判しているのではなく、ただ聞いているだけです。色彩を扱うのが得意なんですね。
色使いがうまいですね。
私もそう思います。しかし、それとは異なるニーズを持つユーザーのカテゴリーが存在します。
また、kanvasインジケーターの戻り値が512を超えた場合はどうなるのでしょうか？この場合、バッファは役に立ちません。そしてユーザーは、自分のプログラムにある指標からデータを受け取りたいだけなのです。そして、彼らはエキスパート-アドバイザーの本体にそれらを埋め込むことを望んでいない（私はフクロウを惜しまない - それは...でガラガラなしで飛ぶことができます）。そして、目に見えるバーだけでなく、要求されたあらゆるバーのデータを受け取りたいと考えています。そして、これは正当なことです。そして、それは怠惰や何でも簡単に手に入れたいという願望だけでなく、TSの要求によって正当化される。
プログラマーでない大多数のユーザーについて言えば、フクロウかインジケーターのどちらかが必要です。フクロウにインジケーターは必要ないそうです。
私は考えるための情報を提供しただけで、何も押し付けているわけではありません。何が便利で何が不便かは、プログラマーが自分で決めればいいのです。しかし、個人的にはiCustom関数を自分のEAで使うことはないと思っています。
もしかしたら、ちょっと違うかもしれませんね。
このようなキャンバスバッファレスインジケーターをマーケットから購入またはダウンロードしたユーザーは、そのデータを自分のEAで使用したいと考えるのは、非常に論理的なことです。
それなら、この指標の製作者が特別に作った構造体を、リソースを通して読み取るというやり取りが最も合理的だと思います。
プログラマは、この構造体がリソースに最新に保たれるように、自分のkanoval bufferless indicatorで注意し、この構造体がユーザイベントを使用して、または各ティック（タイマを使用するのは妥当ではないと思います）の到来時に読み取られるincluファイルをユーザに提供する必要があります。
そして、ユーザーは1行のコード#include...を入れるだけでよいのです。とすると、この構造は常に指標の実データで利用できることになる。
この構造体は、便利な名前の変数や異なる型のデータ配列（古典的なインジケータのバッファのようにダブル型だけではありません）を含むことができるので、iCustomの 古典的な使用よりも 便利なのはお分かりでしょう。
MQのリソースはインジケータのバッファと同じように実装されているはずですが。
ちょっと違うかな。
このようなCanvaインジケータをマーケットから購入またはダウンロードしたユーザーは、そのデータを自分のEAで使いたいと考えるのは、非常に論理的なことです。
この場合、最も合理的なのは、この指標の製作者が特別に作成した構造体を介して交換し、それをリソースで読み取ることだろう。
プログラマは、この構造体がリソース内で最新の状態に保たれるよう配慮し、ユーザイベントを使用してこの構造体を読み込むインクルファイルをユーザに提供する必要があります。
そして、ユーザーは1行のコード#include...を入れるだけでよいのです。であり、この構造は常に指標の実データで利用できることになる。
iCustomの 古典的な使い方よりもさらに便利だと思います。なぜなら、便利な名前の変数やデータ配列を含むことができ、ユーザーはバッファ番号の意味を気にする必要がなく、プログラムにたった1行のコードを含めるだけでインジケータデータに完全に便利にアクセスできるようになるからです。
MQのリソースはインジケータ・バッファと同じように実装されていると思うのですが。
リソースを通じてデータを転送する仕組み自体は、極めてシンプルだ。それよりも、2つのプログラム間の「コミュニケーション」の方法が問題なのです。一方のプログラムは書き込み、もう一方のプログラムは読み出しを行う。したがって、リソースにデータ（インジケータ）を書き込むプログラムは、指定されたメッセージフォーマットを遵守しなければならず、読み込むプログラムはこのフォーマットを「知って」いなければならない。そうすれば、プログラム間のコミュニケーションは普遍的かつ効率的になります。
リソースを通じてデータを転送する仕組み自体は、極めてシンプルだ。それよりも、2つのプログラム間の「コミュニケーション」の方法の方が重要です。一方のプログラムは書き込み、もう一方は読み出しを行う。従って、リソースにデータ（インジケータ）を書き込むプログラムはメッセージのフォーマットを守らなければならず、読み込むプログラムはこのフォーマットを「知って」いなければならない。そうすれば、コミュニケーションは普遍的で応用が効くようになります。
もちろん、そうなります。何しろ、受信と送信の部分は、インジケーターそのものを設計した唯一の開発者が行っているのですから。
リソースを介して共有する仕組みは、それほど単純なものではありません。一定のスキルが必要です。それこそ、より高度なプログラマーの特権になりますから、この方法の長所だと思います。
ZS Peter 1ヵ月前は、極めてシンプルで必要なことだと思えなかったんですね。私のメッセージを聞いて、理解してくれてうれしいです。:))
まあ、当然そうなりますよね。何しろ、受信部と送信部は、このインジケーターを自ら開発したたった一人の開発者が作っているのですから。
資源を介した交換の仕組みは、それほど単純なものではありません。一定のスキルが必要です。それこそ、より高度なプログラマーの特権になりますから、この方法の長所だと思います。
ZS Peter 1ヵ月前は、極めてシンプルで必要なことだと思えなかったんですね。私のメッセージを聞いて、理解してくれてうれしいです。:))
ニコライ リソースは、プログラム間のデータ交換に 非常に有効な手段であることがわかったし、その利用は、君が教えてくれたユニオンに基づいている（バシリイもそうだ）。だから、お二人に感謝します）。
データをリソースに転送し、そこから読み出すという仕組み自体は簡単なのですが、普遍性を追求するとメッセージのフォーマットが厄介なことになります。ある特定の指標について問題を解決すれば、すべてがシンプルになります。