// Открываем объект-отображение FILE_MAP_READ
hMMF = OpenFileMapping( FILE_MAP_WRITE,FALSE, lpFileShareName);// Если открыть не удалось, выводим код ошибкиif( hMMF ==NULL){MessageBox(NULL,"OpenFileMapping: Error","RealTimeData", MB_OK );return0;}// Выполняем отображение файла на память FILE_MAP_READ // В переменную lpMMF будет записан указатель на отображаемую область памяти
lpMMF = MapViewOfFile( hMMF, FILE_MAP_WRITE,0,0,sizeof( NSDTfeedTick));// Если выполнить отображение не удалось, выводим код ошибкиif( lpMMF ==0){MessageBox(NULL,"MapViewOfFile: Error","RealTimeData", MB_OK );return0;}//---
レジストリに代わるものとして、単純なファイル共有があります。(NTFSファイルシステムのことです)
2つの端末 c:\mt1, c:\mt2 があり、それぞれにはもちろん \experts があります。
Create c:\mt1Experts Philexchange c:\mt2Experts Philexchange
Windows Server 2003 Resource KitTools(for win 2000,2003,xp) から linkd コマンドを vista MKLINK で作成する。
linkd.exe c:\mt1╱╱ c:\mt2╱╱╱╱╱...
は、これで端末との共有ディレクトリになりました。(Copy any file to c:\mt1╱experts╱files╱andbrowse to c:\mt2╱experts╱ )
は、Far - Alt F6で同じことができます。
レジストリに代わるものとして、単純なファイル共有があります。(NTFSファイルシステムのことです)
2つの端末 c:\mt1, c:\mt2 があり、それぞれにはもちろん \experts があります。
Create c:\mt1Experts Philexchange c:\mt2Experts Philexchange
Windows Server 2003 Resource KitTools(for win 2000,2003,xp) から linkd コマンドを vista MKLINK で作成する。
linkd.exe c:\mt1╱╱ c:\mt2╱╱╱╱╱...
は、これで端末との共有ディレクトリになりました。(Copy any file to c:\mt1╱experts╱files╱andbrowse to c:\mt2╱experts╱ )
は、Far - Alt F6 でも同じことができます。
それでも、ファイルによるコミュニケーションは正しいツールではありません。正しいものではありません。
ファイルは、長い間、情報を保存するために発明されたものです。なぜわざわざディスクを使うのか？通信用のRAMがあります。
その後、受信されます。
2009.05.19 01:22:16 2008.12.31 01:49 temp EURUSD,M1: ####.
2009.05.19 01:22:16 2008.12.31 01:49 temp EURUSD,M1: RegCreateKeyExA(): 存在しないパーティションが作成されました。
2009.05.19 01:22:16 テスト用テンプレ開始
つまり、呼び出し時にエラーは発生しないが、バッファの内容は変化しない。そして、レジストリには、まさに「Test」文字列が含まれています。
フォーラムの 投稿から、MQL環境からDLL関数への異常な文字列の受け渡しが原因で起こることを理解しました。MQL環境では、開発者は独自のマネージャ（文字列プール）を使って文字列を操作しますが、どうやらこの境界では間違ったバッファが埋められ、API関数が返す結果を見ることができないようなのです。しかし、最大長をすべて初期化した文字列を使えば、私が見る限り、問題はない。そのため、255文字の「#」という文字列があるのです。文字列を目に見えるようにするために、単純に「#」という文字が選ばれている。呼び出す前にバッファに何が入っているかは関係ないので、Win API自体には関係ない。これは、先ほどの文字列の長さの制限のことです。SetStringValue()に255文字より長い文字列を渡すことはできますが、読み込みに失敗します。
もちろん制限がないに越したことはないのですが、大きな不便を感じることはありません。なぜ、あるサイズの文字列を読み取る必要があるのか、という疑問が湧いてきます。制約の話なら、入力文字列を長さ255＋「余り」パラメータでN個のパラメータに分割する関数を書けば、制約を回避することができます。そして、読むときには、それを集め直す。それ以外の方法はない。もし、難しい場合は、私に連絡してください。単に、誰もが異なるニーズを持って、我々はすべてを提供することはできません、それは私のためにこれだけで十分であり、誰かがグローバル変数を使用し、さらにいくつかのレベルである。
混乱してるんだ...255文字という制限はどこにあるのですか？MQL4にはそのような制限がないことは事実です。
例のコードがさりげなくヒントになりました :-))
それでも、ファイルによるコミュニケーションは適切なツールとは言えません。道具としてふさわしくない。
ファイルは、情報を長期間保存するために考案されたものです。なぜディスクを苦しめるのか？通信用のRAMがあります。
私も一部同意見です。
RAMを通すことはできますが、それは難しいです（結局のところ、フォーラムは100％のシステムプログラマではなく、50％でもありません）。
そして、もう少し広く見てみると、unixでは、すべてのファイル、RAM、ディスク、プロセスです。
私は、多くの方法のうちの1つを提案しただけです。
意味がわからない...。255文字の制限はどこにあるのですか？MQL4にはそのような制限がないことは事実です。
コードサンプルは質問の本質をさりげなくほのめかしていました :-))
さて、プログラム実行中に文字列をインクリメントした場合、制限はありませんが、その後、文字列定数でなくなることが判明しました。文字列定数の長さについては、ドキュメントに非常に明確に記載されています。
文字列定数の長さは、0～255文字である。文字列定数が最大長を超えた場合、不要な文字は右に切り捨てられ、コンパイラは対応する警告を生成します。
まあ、プログラム実行中に文字列を増やせば制限はないのですが、そうなると文字列定数ではなくなってしまいます。文字列定数の長さについては、こちらの ドキュメントに明確に書かれています。
我々の場合、それが定数であるかどうかは問題ではありません。
では、変数を使えば、もっといろいろなことができるのですか？
私たちの場合、それが定数かどうかは問題ではありません。
では、もっと、変数でできるのですか？
なぜ、関係ないのですか？なぜなら、バッファが一定の文字列であればAPIコールは正常に動作し、バッファが「動的に」作成された文字列であればAPIコールはエラーなく動作するからです。しかし、先に述べた理由により、レジストリからのデータはこの文字列では観測されません。
Andres さんが書き込みました >>1
プログラム実行中に文字列を増加させる必要がある場合、文字列は無制限に増加しますが、その場合、文字列定数でないことが判明します。ドキュメントによると、文字列定数の長さについて明確になっているそうです。
ここでは、ライブラリの制限ではなく、文字列の長さの制限について述べています。
レジストリから文字列定数でデータを取得する方法と、文字列を動的にインクリメントする方法を試してみると、その違いがわかると思います。前者ではデータが入り、後者ではデータが入らない。
ここでは、ライブラリの制限ではなく、文字列の長さの制限について述べています。
文字列定数と動的にインクリメントされる文字列を使ってレジストリからデータを取得してみれば、その違いがわかるはずです。前者の場合はデータを受信し、後者の場合は受信しない。
>>...変！...です。つまり、関数のどこでメモリを確保するかが重要であることがわかったのですね。
プログラム間のデータ交換は、仮想ファイルによるのがベストだと思います。
などなど......。
すべてが不具合なく、確実に動く...。電子的にテストされた :)
プログラム間のデータ交換は、仮想ファイルによるのがベストだと思います。
などなど......。
すべてが不具合なく、確実に動く...。電子的にテストされた :)
全くその通りです。FileMappingは、最も簡単ではないものの、素晴らしいツールです。パイプやメールスロットも試してみてはいかがでしょうか。