私のアプローチコアはエンジンです。 - ページ 97 1...90919293949596979899100101102103104...184 新しいコメント Реter Konow 2018.12.20 16:35 #961 Vasiliy Sokolov:ピーター、糸って一体なんだ！？double、int、colorなどのパラメータを文字列に変換して、チャート上のオブジェクトに書き込むのです。しかし、ユニオンで作業する場合、文字列は必要ありません。この例では、文字列を使わずに直接doubleを操作しており、データもきちんと渡されています。バシリイ カスタムEAでは、数値データだけでなく、文字列データも多くエンジンに設定します。名前、メッセージなどですから、数字だけでは無理なのです。 例えば、Oleg Papkov氏のExpert Advisorは、「The trend went up, trend went down...」といった文章をウィンドウに表示します。また、テーブルのセルにテキストを渡したい人もいるでしょう。入力フィールド に 数字だけではどうしようもない...。(( Vasiliy Sokolov 2018.12.20 16:39 #962 テキストを渡す必要がある場合は、文字列をバイトの配列に変換してください。 StringToCharArray("text", u.char); ここで、uはunion、u.charはchar[]の配列です。ユニオン配列のサイズは固定なので、文字列が収まらない場合は、u.charを大きくするか、文字列を分割して渡します。 Реter Konow 2018.12.20 16:46 #963 Vasiliy Sokolov:テキストを渡す必要がある場合は、文字列をバイトの配列に変換してください。 ここで、uはunion、u.charはchar[]の配列です。ユニオン配列は固定サイズになるので、文字列が入りきらない場合は、u.charを拡張するか、文字列を分割して渡すようにします。なるほど、ありがとうございます。これから試してみます。(しかし、リソースを完全に理解したいのです。これも便利かもしれませんね。 追加機能はいつでも便利です。そして、新しい知識を得るのも悪くない...。 要するに、個人的にもみなさんにも大変 お世話になったということです。 Vasiliy Sokolov 2018.12.20 16:50 #964 Реter Konow:なるほど、ありがとうございます。試してみます。(とはいえ、すべてをオブジェクトの記述で 済ませればいいのですが）、リソースの真相に迫りたいと思います。これも便利かもしれませんね。 追加機能はいつでも便利です。そして、新しい知識を得るのも悪くない...。 要するに、個人的にもみなさんにも大変 お世話になったということです。高速通信を望むなら、これ以上のスピードはないでしょう。オブジェクトに渡すパラメータ付きの文字列は非常に速く、もしかしたらResourceCreateよりも速いかもしれませんが、この文字列のパースですべての速度が失われるでしょう。しかし、MQLは非常に高速な言語であり、ここでは遅いパースでも比較的高速に処理することができます。 Реter Konow 2018.12.20 16:55 #965 Vasiliy Sokolov:高速通信を望むなら、ユニオンより速いものはない。オブジェクトを通してパラメータ付きの文字列を渡すのは本当に速く、もしかしたらResourceCreateよりも速いかもしれませんが、この文字列のパースが速度を殺してしまいます。しかし、MQLは非常に高速な言語であり、ここでは遅いパースでも比較的高速に処理することができます。問題は、いずれにしても構文解析が必要になることです。結局、リソースに文字列を書き込んだとしても、そこから文字列を抽出して収集し、「パラメータ番号／パラメータ値」に分割しなければならない。 つまり、リソースから壊れた文字列を一度に取り出すことはほとんどできない。そのため、パースもまだ必要です...(( Vasiliy Sokolov 2018.12.21 09:52 #966 Реter Konow:問題は、いずれにしても構文解析が必要になることです。結局、リソースに文字列を書き込んだとしても、そこから文字列を取り出し、収集し、「パラメータ番号／パラメータ値」に分割する必要があるのです。 つまり、リソースから壊れた文字列を一度に取り出すことはほとんどできない。ということは、まだパースが必要なんですね...((ピーター、またやってくれたな。何度目だろう？すでに何度も言われていることですが、文字列を使わずに値やパラメータ番号を渡すことができます。この例では、文字列を解析することなく、double を渡しています。では、なぜこのダブルを再び文字列にしようとするのでしょうか？ユーザーにメッセージを渡す必要がある場合 - パースせずにテキストとして渡します。それだけです。 Реter Konow 2018.12.21 11:21 #967 Vasiliy Sokolov:ピーター、またやってくれたね。何度言われたことか。何度も言われていることですが、文字列を使わずにパラメータ値や数値の受け渡しをすることができます。この例では、文字列を解析することなく、double を渡しています。では、なぜこのダブルを再び文字列にしようとするのでしょうか？ユーザーにメッセージを渡す必要がある場合 - パースせずにテキストとして渡します。それだけです。バシリー 説明させてください。 パラメータ値は数値だけではありません。パラメータ値には、テキストを指定することができます。例えば、ユーザーが入力フィールドにテキストを入力したとする。このテキストは、エンジンからExpert Advisorに転送されます。あるいは、Expert Advisorは特定のイベント時にGUIにテキストを送信し、「A trading session has started! イベントごとに、Expert Advisor やエンジンはすべての型（int, double, long, string...）のデータをやり取りする必要があるため、すべてを文字列で一度に渡し、その後目的の型にキャストする方が便利です。 そうでなければ、あるデータを渡す方法と、他のデータを渡す方法があります。 ユーザーがどのようなデータを転送するのか、あるいはさらに受け取るのか、誰も知らないのです。もしかしたら、メインのデータになるのはテキストになるかもしれませんね。どこから見ても、糸は情報を送受信する普遍的な媒体であることがわかる。 Реter Konow 2018.12.21 11:25 #968 Vasiliy Sokolov: ところで、昨日の解決策（と皆さんの協力）のおかげで、一歩前進しましたので、ご覧ください。 この例では、すべてがリソースを介して渡されます。 そして、それはすべてEAの中のこのコードを通して行われます。 void OnTimer() { static int q1,q2,q3,a,b,c,d; //------------------------------------ LOAD_CANVAS_Last_10_bars(); //--------------------------------- if(!a) { q1++;} if(q1 == 200)a = 1; if(a)q1--; if(!q1)a = 0; //------------------------------------ CIRCLE(q1,q2,q3,clrGreen); TRIANGLE(q1,q1,q1 + 100,q1 + 10,q1 + 50,q1 + 200,clrRed); ELLIPSE(q1,q1,q1 + q1*2,q1 + q1,clrBlue); FILLED_CIRCLE(q1,20,20,clrBlue); TRIANGLE(q1 + 10,q1,q1 + 10,q1 + 100,q1 + 50,q1 + 200,clrAqua); ELLIPSE(q1 + 50,q1,q1 + q1*2,q1 * q1-30,clrBlack); ELLIPSE(q1 + 52,q1,q1 + q1*3,q1 * q1-32,clrMagenta); ELLIPSE(q1 + 54,q1,q1 + q1*4,q1 * q1-34,clrOrange); FILLED_CIRCLE(q1 + 70,q1+20,20,clrDarkCyan); FILLED_CIRCLE(q3,q2,40,clrGreen); //------------------------------------ REDRAW_CANVAS(); } Vasiliy Sokolov 2018.12.21 11:27 #969 Реter Konow:ところで、昨日の解決策（と皆さんの協力）のおかげで、一歩前進しましたので、ご覧ください。 この例では、すべてがリソースを通じて転送されます。はい、見ごたえがありますね。 Vasiliy Sokolov 2018.12.21 11:43 #970 Реter Konow:どこから見ても、文字列は情報を送受信する普遍的なメディアであるように見える。ここは同意しかねます。情報伝達の万能選手といえば、バイト配列。 テキストも転送するべきだというのは、私も同感です。あと、テキストを文字列で渡すのが良いというのも同意です。しかし、実は文字列というのは抽象的なもので、グラフ内のオブジェクトを介してテキストを渡す場合、このテキストの長さは64文字に制限されていました。つまり、裏では実際には64バイトの配列を渡していたのです（文字列を 配列に変換する作業はすべてMQLが行っており、明示的に行っているわけではありません）。MQLプログラム間の情報交換がプロジェクトの重要かつ基本的なポイントになるようなプロジェクトであれば、この機能を汎用的なソリューションに委ねるのは論外です。私だったら、文字列を含む任意の型に対して、厳密な変換制御を行う汎用的な転送システムを開発しますよ。これは構文解析やリソースの読み込みをベースに行うことができる。しかし、文字列のパースに関しては、パースされた文字列が有効である保証がないため、問題がある。 1...90919293949596979899100101102103104...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ピーター、糸って一体なんだ！？double、int、colorなどのパラメータを文字列に変換して、チャート上のオブジェクトに書き込むのです。しかし、ユニオンで作業する場合、文字列は必要ありません。この例では、文字列を使わずに直接doubleを操作しており、データもきちんと渡されています。
バシリイ カスタムEAでは、数値データだけでなく、文字列データも多くエンジンに設定します。名前、メッセージなどですから、数字だけでは無理なのです。
例えば、Oleg Papkov氏のExpert Advisorは、「The trend went up, trend went down...」といった文章をウィンドウに表示します。また、テーブルのセルにテキストを渡したい人もいるでしょう。入力フィールド に
数字だけではどうしようもない...。((
テキストを渡す必要がある場合は、文字列をバイトの配列に変換してください。
ここで、uはunion、u.charはchar[]の配列です。ユニオン配列のサイズは固定なので、文字列が収まらない場合は、u.charを大きくするか、文字列を分割して渡します。
テキストを渡す必要がある場合は、文字列をバイトの配列に変換してください。
ここで、uはunion、u.charはchar[]の配列です。ユニオン配列は固定サイズになるので、文字列が入りきらない場合は、u.charを拡張するか、文字列を分割して渡すようにします。
なるほど、ありがとうございます。これから試してみます。(しかし、リソースを完全に理解したいのです。これも便利かもしれませんね。
追加機能はいつでも便利です。そして、新しい知識を得るのも悪くない...。
要するに、個人的にもみなさんにも大変 お世話になったということです。
なるほど、ありがとうございます。試してみます。(とはいえ、すべてをオブジェクトの記述で 済ませればいいのですが）、リソースの真相に迫りたいと思います。これも便利かもしれませんね。
追加機能はいつでも便利です。そして、新しい知識を得るのも悪くない...。
要するに、個人的にもみなさんにも大変 お世話になったということです。
高速通信を望むなら、これ以上のスピードはないでしょう。オブジェクトに渡すパラメータ付きの文字列は非常に速く、もしかしたらResourceCreateよりも速いかもしれませんが、この文字列のパースですべての速度が失われるでしょう。しかし、MQLは非常に高速な言語であり、ここでは遅いパースでも比較的高速に処理することができます。
高速通信を望むなら、ユニオンより速いものはない。オブジェクトを通してパラメータ付きの文字列を渡すのは本当に速く、もしかしたらResourceCreateよりも速いかもしれませんが、この文字列のパースが速度を殺してしまいます。しかし、MQLは非常に高速な言語であり、ここでは遅いパースでも比較的高速に処理することができます。
問題は、いずれにしても構文解析が必要になることです。結局、リソースに文字列を書き込んだとしても、そこから文字列を抽出して収集し、「パラメータ番号／パラメータ値」に分割しなければならない。
つまり、リソースから壊れた文字列を一度に取り出すことはほとんどできない。そのため、パースもまだ必要です...((
問題は、いずれにしても構文解析が必要になることです。結局、リソースに文字列を書き込んだとしても、そこから文字列を取り出し、収集し、「パラメータ番号／パラメータ値」に分割する必要があるのです。
つまり、リソースから壊れた文字列を一度に取り出すことはほとんどできない。ということは、まだパースが必要なんですね...((
ピーター、またやってくれたな。何度目だろう？すでに何度も言われていることですが、文字列を使わずに値やパラメータ番号を渡すことができます。この例では、文字列を解析することなく、double を渡しています。では、なぜこのダブルを再び文字列にしようとするのでしょうか？ユーザーにメッセージを渡す必要がある場合 - パースせずにテキストとして渡します。それだけです。
ピーター、またやってくれたね。何度言われたことか。何度も言われていることですが、文字列を使わずにパラメータ値や数値の受け渡しをすることができます。この例では、文字列を解析することなく、double を渡しています。では、なぜこのダブルを再び文字列にしようとするのでしょうか？ユーザーにメッセージを渡す必要がある場合 - パースせずにテキストとして渡します。それだけです。
バシリー 説明させてください。
パラメータ値は数値だけではありません。パラメータ値には、テキストを指定することができます。例えば、ユーザーが入力フィールドにテキストを入力したとする。このテキストは、エンジンからExpert Advisorに転送されます。あるいは、Expert Advisorは特定のイベント時にGUIにテキストを送信し、「A trading session has started!
イベントごとに、Expert Advisor やエンジンはすべての型（int, double, long, string...）のデータをやり取りする必要があるため、すべてを文字列で一度に渡し、その後目的の型にキャストする方が便利です。
そうでなければ、あるデータを渡す方法と、他のデータを渡す方法があります。
ユーザーがどのようなデータを転送するのか、あるいはさらに受け取るのか、誰も知らないのです。もしかしたら、メインのデータになるのはテキストになるかもしれませんね。どこから見ても、糸は情報を送受信する普遍的な媒体であることがわかる。
ところで、昨日の解決策（と皆さんの協力）のおかげで、一歩前進しましたので、ご覧ください。
この例では、すべてがリソースを介して渡されます。
そして、それはすべてEAの中のこのコードを通して行われます。
ところで、昨日の解決策（と皆さんの協力）のおかげで、一歩前進しましたので、ご覧ください。
この例では、すべてがリソースを通じて転送されます。
はい、見ごたえがありますね。
どこから見ても、文字列は情報を送受信する普遍的なメディアであるように見える。
ここは同意しかねます。情報伝達の万能選手といえば、バイト配列。
テキストも転送するべきだというのは、私も同感です。あと、テキストを文字列で渡すのが良いというのも同意です。しかし、実は文字列というのは抽象的なもので、グラフ内のオブジェクトを介してテキストを渡す場合、このテキストの長さは64文字に制限されていました。つまり、裏では実際には64バイトの配列を渡していたのです（文字列を 配列に変換する作業はすべてMQLが行っており、明示的に行っているわけではありません）。MQLプログラム間の情報交換がプロジェクトの重要かつ基本的なポイントになるようなプロジェクトであれば、この機能を汎用的なソリューションに委ねるのは論外です。私だったら、文字列を含む任意の型に対して、厳密な変換制御を行う汎用的な転送システムを開発しますよ。これは構文解析やリソースの読み込みをベースに行うことができる。しかし、文字列のパースに関しては、パースされた文字列が有効である保証がないため、問題がある。