В MQL5 параметры простых типов можно передавать как по значению, так и по ссылке, в то время как параметры сложных типов всегда передаются по ссылке. Для указания компилятору на необходимость передачи параметра по ссылке, перед именем параметра ставится знак амперсанда Передача параметра по ссылке означает передачу адреса переменной, поэтому...
うーん...。私がAPIをよく見ていなかったのかもしれませんが、そのような機能は見当たりませんでした...。そして、それはおそらく便利なものでしょう。
他に何かコツがあれば...。もってのほかdoubleなどの数値を配列のcharに変換するには？つまり、あるAPIでは数値をポインタとして渡すことが要求されているのです。ポインターは1次元配列として渡され...文字列の場合はStringToShortArrayと StringToCharArrayという関数が 用意されているのでわかるのですが、数値の場合はバイト配列（char）に変換する方法がまだわかりません。
例えば？
十分に行き渡らない。レジストリを使った作業を見てみましょう。レジストリには、文字列と数値の両方を格納することができます（文字列としては格納できません）。レジストリに数値を渡してポインタを返すのは、（訂正によると）配列を介して行われるそうです。このような例は有効でしょうか？
ダニの歴史を研究しています。ティックの時間に市場で何が起こっていたのか、いつもうまくいくわけではありません。
エスビーエル
i=987 2016.06.27 10:00:30.274 Ask=133.91 Bid=133.9 Last=133.9 Vol=50 TICK_FLAG_ASK
i=988 2016.06.27 10:00:30.280Ask=133.93 Bid=133.9 Last=133.9 Vol=50 TICK_FLAG_ASK
i=989 2016.06.27 10:00:30.280 Ask=133.93 Bid=133.9Last=133.91 Vol=100 TICK_FLAG_LAST TICK_FLAG_VOLUMETICK_FLAG_BUY TICK_FLAG_SELL
i=990 2016.06.27 10:00:30.280 Ask=133.93 Bid=133.9 Last=133.92 Vol=300 TICK_FLAG_LAST TICK_FLAG_VOLUMETICK_FLAG_BUY TICK_FLAG_SELL
i=991 2016.06.27 10:00:30.280 Ask=133.93 Bid=133.9 Last=133.92 Vol=100 TICK_FLAG_LAST TICK_FLAG_VOLUMETICK_FLAG_BUY TICK_FLAG_SELL
i=992 2016.06.27 10:00:30.281 Ask=133.94 Bid=133.9 Last=133.92 Vol=100 TICK_FLAG_ASK
1.TICK_FLAG_BUYとTICK_FLAG_SELLの フラグを同時に持つ謎のティックは何ですか？ 私は1ロットのボリュームでそのようなティックを見つけることができました。
2.988の刻みで。Ask=133.93 Bid=133.9 Last 133.91 Where did I come from 989 ?
市場で何が起こったのか？
そのような質問は、フォーラムの「株式取引」セクションの別のスレッドに投稿する方がよいでしょう。
要するに、あるティックに買いフラグと売りフラグが同時に立っている場合、ブローカーのサーバーが更新されておらず、方向が不明なディールをブロードキャストしていることを意味します。
どのサーバーでティックを見るのですか？質問を書き直すか、句読点をつけるか、いっそのこと、何が、どこで、誰が、という絵を添えてください。そうでないと、見慣れた文字が見えても、意味や思いが伝わらないんです。
以下は写真です。
これが写真です。
では、なぜ私の写真を入れたのか（キャッシュが狂っているのか？）
以下は写真です。
ターミナルでマウスを直接動かして、右クリックでポジションの価格を コピーするのですか？
十分に行き渡らない。レジストリを使った作業を見てみましょう。レジストリには、文字列と数値の両方を格納することができます（文字列ではありません）。レジストリに数値を渡してポインタを返すのは、（訂正によると）配列を介して行われるそうです。このような例は有効でしょうか？
お待たせしました。きっとわかると思うんです。
それは、オリジナル！？考えたこともなかった。)))
前回の例にならって、メモリと端末がクラッシュする原因を探ってみました。
まず、開いているレジスタ・セクションへのポインタを取得するために配列を拒否しました。つまり、単純にuint& phkResultをAPIに渡しただけです。すべてうまくいき、エラーも出ませんでした。mqlのドキュメントには、単純な型は参照渡しできると書いてあるが、これはAPIで作業する場合、変数のアドレス、つまりポインタである。この部分は、すべてが成功でした。私もNULLパラメータを返して、配列を使わずに渡しています。
さらに、値そのものをレジスタに渡す作業を行いました。関数の説明では、末尾に0をつけた文字列を渡すように指摘されています。これはまさに文字列型 なので、最初のバージョンではただの変数を渡していました。前のバージョンでは、同じに頼って変更しなかったのですね。しかし、配列の実験をしてみようと思い、ushort配列を導入し、必要な値を入れてみました。関数に渡すときのパラメータの1つ
uint RegSetValueExW(uint hKey, string lpValueName, uint Reserved, uint dwType, ushort &lpData[], uint cbData)
は、渡されるデータのサイズである。あなたの例では、こんな感じでした。
uint cbData = (StringLen(value)+1)*2;
ここではすべてがクリアになる。文字列の長さを取り、「終わり」の0を加え、2バイトを掛けて、ushortサイズとする。
こんな風にやってみました。
ushort Data[];
StringToShortArray(value, Data);
uint cbData = sizeof(Data);
データのサイズが前の例と同じでなかったときの私の驚きを想像してください。
配列のサイズを確認したところ、StringLen(value)+1と絶対的に等しかったのですが、データサイズは同じではありません...。今でもその理由がわからない。
でも、気にしないでください。
結局元々の問題は、文字列変数をポインタとして参照渡ししていたため、レジストリから値を取得することでした。ここで事故が発生した。
「なぜなら、システムのDLLは、この構造体ではなく、末尾にゼロ文字を持つ正直な文字列を確実に受け入れるから です」 - この引用は10年前のものですが、関連性は失われていません。
したがって、レジストリセクション名や文字列パラメータ値などの文字列定数値を渡しても、すべて正しく動作します。また、私のように文字列変数を参照渡しする場合、引用文にあるような問題が発生します。)))
また、受信サイズについては、APIドキュメントに例がありますが、「データが足りない」というエラーの場合、ループ内で受信バッファサイズを大きくして、再度データを取得するようにしています。
つまり、こんな感じです。
また、お世話になります)))
それは、オリジナル！？考えたこともなかった。)))
ユニオンは使い勝手がいい。どこが高バイトでどこが低バイトかを考える必要はありません。ユニオンはREG_BINARYにも使用可能です。データ構造を記述するのです。そして、構造体サイズ別のバイト配列と一緒にUnionに追加するのです。でも、本当は必要ないんじゃないかと思うんです。あらゆるデータを文字列に変換し、文字列として保存することができる。
スタックが飛んでいたためか、関数の説明でintではなくlongを指定している可能性があります。
このセクションのドキュメントへのリンクをダウンロードできますか？
ushort配列を渡す場合、uint cbData = ArraySize(Data) * 2 が必要です。
であり、配列ucharを渡す場合は、uint cbData = ArraySize(Data)となります。
最後の例では、WindのLPBYTE lpDataとの完全な互換性を保つために、API関数のパラメータとしてuchar配列を渡しています。正しいのです。しかし、すべてのデータをバイト配列に変換するのは手間がかかる。
最後のコードを見てみましょう。そこでは、まずデータのサイズを取得する要求があり、次に配列のサイズが設定 され、そしてすべてのデータがそのまま取り込まれる実装になっています。
ユニオンは使い勝手がいい。どこが高バイトでどこが低バイトかを考える必要はないのです。REG_BINARYでもUnionを使用することができます。データ構造を記述するのです。そして、構造体サイズ別のバイトの配列と一緒にUnionに追加します。でも、本当は必要ないんじゃないかと思うんです。あらゆるデータを文字列に変換し、文字列として保存することができる。
また、スタックが飛んでいたためか、関数の説明でintではなくlongを指定していますね。
このセクションのドキュメントへのリンクをダウンロードできますか？
ushort配列を渡す場合、uint cbData = ArraySize(Data) * 2 が必要です。
であり、配列ucharを渡す場合は、uint cbData = ArraySize(Data)となります。
最後の例では、Windows の LPBYTE lpData と完全な互換性を保つために、uchar 配列を API 関数パラメータとして渡しています。正しいのです。しかし、すべてのデータをバイト配列に変換するのは手間がかかる。
最後のコードを見てみましょう。そこでは、まずデータのサイズを取得する要求があり、次に配列のサイズが設定 され、そしてすべてのデータがそのまま取り込まれる実装になっています。
改めてご挨拶申し上げます。
このスレッドでの議論が、初心者だけでなく、経験豊富なプログラマーにとっても有益なものになることを心から願っています。
ロングではどうでしょう。はい、私のミスですが、最初使われていたのはintでした。64bitの端末を使っているのでLongを使いました。しかし、intではすべてがうまく機能します。
ポインターについて。以下の記事によく書かれていると思います。https://www.mql5.com/ru/docs/basis/types/this、https://www.mql5.com/ru/docs/runtime/imports。
私もsizeofの間違いは認めます。今回は交換用の動的配列を使っていますが、動的配列の場合、sizeofはデータサイズではなく、単に配列そのもののサイズを返します。https://www.mql5.com/ru/docs/basis/operations/other。
原寸大のデータ取得について。はい、おっしゃるとおりです。確かに、最初の呼び出しで、関数はパラメータに置かれたデータのサイズを返すので、私が書いたようなループは必要ありません。ここで、関数の説明を誤解していたようです。変数が読み込んだデータのサイズを返すと書いてあります。
文字列に戻ろう...。原理的には、データを受け取るときに、参照で変数を渡すこともできるが、まずは最大長までの何らかの値で初期化すればよいことがわかった。これは、その後、この文字列から値そのものを切り取るべきであり、ひつような気がします。配列バッファからデータを取得する方がより最適であり、私たちのソリューションの方が優れていると思います ))) 。
文字列のポインタ渡しについてはこちらhttps://www.mql5.com/ru/forum/103532/page2#comment_2983919
そして、Andriyはdllを使った仕事について非常によく語ってくれています。https://www.mql5.com/ru/articles/96。
レジストリだけでなく、ライブラリAPIのニュアンスも含めて、皆さんの協力で完全にカバーできたと思います。
レジストリを扱うクラスは、1つのチャート上のツール間でも、一般的なチャートと端末の間でも、データのやりとりに非常に便利です。
以前、このフォーラムで、これらの目的のためにレジストリを使用することは、電球で釘を打つことに等しいと言われ、仮想ファイル（マッピング）の使用を提案されました。しかし、レジストリをディスクに書き込む前は単なる仮想ファイルなので、これには納得がいきません。また、REG_OPTION_VOLATILE属性を使用する場合、その値は常にvirtualとなります。そして、セッション間のデータをレジストリに保存しておくと非常に便利です。IMHO