Сокеты… Что вообще сейчас в нашем информационном мире может без них существовать? Впервые появившиеся в 1982 г. и практически не изменившиеся до настоящего времени, они исправно работают на нас каждую секунду. Это основа сети, нервные окончания нашей Matrix, в которой мы живем. Утром вы включили терминал MetaTrader, и он сразу создал сокеты и...
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг handle=InitDLL(flags); // ... // опрос типично выглядит так: while ( flags[0] ) // проверить один int это очень быстро { flags[0]--; ReadDataFromDLL(handle); }
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг handle=InitDLL(flags); // ... // опрос типично выглядит так: while ( flags[0] ) // проверить один int это очень быстро { flags[0]--; ReadDataFromDLL(handle); }
実は、そうではないんです。外部プログラムとMT内のプログラムに違いはない。能力も同じ、インタラクションも同じ。
全く説明になっていませんね。シャープパネルでMT*からデータを取得する方法を教えてください。
私は、タイムドポーリングによるメモリーマッピングでフィードバックを行っています。パネルが違う設定を送ってきたり、計算結果が遅かったりするだけでした。
無知は自信を与える。しかし、知識は悲しみを増長させる。
よし、それならパネルを分離して、Memory Mappingで通信させることにしよう。2000年代後半にパイプ経由でやっていたのですが、好きではありませんでした。
直接接続したため、ホラーには気づかなかったが。
端末のCOMインターフェースは、急速に陳腐化しつつあるが、クールであろう。
ただ、現実の時間には合わないようです :-)。
COMインターフェース は、おそらく利用できないでしょう。
しかし、なぜ時代遅れなのか聞いてみてもいいでしょうか。
また、陳腐化も早い。
COMインターフェース は、おそらく利用できないでしょう。
しかし、なぜ時代遅れなのか聞いてみてもいいでしょうか。
また、急速に陳腐化しつつあります。
通信インターフェースを持つ.netに取って代わられました。
通信インターフェースを持つ.netに取って代わられました。
で、COMのGUIDだけでもかなりの価値があります。
MSは今でも未使用のGUIDを1ドル10セントで買い取りしている。昔のものが残っていれば、いい儲けもの!
また、COMではGUIDだけでもかなりの価値があります
MSは今でも未使用のGUIDを1ドル10セントで買い取りしている。昔使っていたものが残っていれば、いい儲けもの!
私はいくつか転がっている :-) MSに送らせてください
066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb
があれば、見つけられるかもしれませんね。
同僚どの開発環境が優れているか、どのコードが速いかという議論は、全く意味がないと思います。それはすべて好みの問題であり、解決すべき課題によって異なります。開発環境に関わらず、外部アプリケーションとMetaTraderツールの相互作用の問題が残っています。簡単な例で考えてみましょう。複雑な数学計算 のアルゴリズムをネイティブDLで実装している。MTツールからこのライブラリに必要なパラメータを渡して計算を開始すると、計算が完了するまでツールは作業を続けます。そしてまた、この問題は開発環境には依存しないのです
いくつかの選択肢があるようですね。
1.プログラムの外側からOnChartEventメソッドを呼び出すことができるようになり、例えばPostMessage
2.МТツールに新しいメソッドを追加し、Renatが提供するように：OnExternal、イベントの種類や一般的に転送されたデータを指定する、つまり、このメソッドでは、データを返すことができます。
3.winsocketのMTツールへの実装。これは2番目のポイントと似ていますが、MTツールが特定のポートに接続してデータを待ち受けることができるようにするものです。
1番目と2番目の項目で1台のマシンレベルでの対話が可能になるとすれば、3番目の項目はネットワーク通信を備えたMTツールを提供することになります。
以下はその例です:https://www.mql5.com/ru/articles/2599
しかし、ここでもソケットのデータが常に利用可能かどうかをチェックしなければならないという問題が発生します。
そのため、どのような場合でもコールバックの問題は残り、解決には至らない。
タイマー監視は解決策ではなく、鎹（かすがい）です。そう、他に選択肢がない以上、今はこの方法で解決しているのです。
もし、開発者がこれらの問題を解決する方法をプラットフォームレベルで実装してくれれば、端末のAPIにアクセスする必要はなくなるはずです。結局のところ、いい加減な生活をしているから求められるのではなく、MTと作成されるアプリケーションとの間に本格的なやりとりがないからこそ、求められているのです。そして、繰り返しになりますが、この問題は、選択した外部アプリケーションの開発環境に関係なく存在します。
ネットライブラリの利用可能性に関する情報 )))https://www.mql5.com/ru/forum/13388
この話題は原理的に非常に古いものです。開発者自身が、ネットライブラリとの連携は問題ないと発表していたのに......その後、いろいろな水が流れましたが、この問題は未解決のまま......。
また、レナト本人からのメッセージはこちらです。https://www.mql5.com/ru/forum/3153/page2#comment_298866。
https://www.mql5.com/ru/forum/3153/page2#comment_298892
同僚どの開発環境が優れているか、どのコードが速いかという議論は、全く意味がないと思います。これは好みの問題であり、解決すべき課題によって異なります。開発環境に関わらず、外部アプリケーションとMetaTraderツールの相互作用の問題が残っています。簡単な例で考えてみましょう。複雑な数学計算 のアルゴリズムをネイティブDLで実装している。MTツールからこのライブラリに必要なパラメータを渡して計算を開始すると、計算が完了するまでツールは作業を続けます。そしてまた、この問題は開発環境とは無関係なのです!
いくつかの選択肢があるようですね。
1.プログラムの外側からOnChartEventメソッドを呼び出すことができるようになり、例えばPostMessage
2.МТツールに新しいメソッドを追加し、Renatが提供するように：OnExternal、イベントの種類や一般的に転送されたデータを指定する、つまり、このメソッドでは、データを返すことができます。
3.winsocketのMTツールへの実装。これは2番目のポイントと似ていますが、MTツールが特定のポートに接続してデータを待ち受けることができるようにするものです。
1番目と2番目の項目で1台のマシンレベルでのインタラクションが可能になるなら、3番目の項目はMTツールのネットワーク化を実現することになる。
以下はその例です:https://www.mql5.com/ru/articles/2599
しかし、ここでもソケットのデータが常に利用可能かどうかをチェックしなければならないという問題が発生します。
そのため、どのような場合でもコールバックの問題は残り、解決には至らない。
タイマー監視は解決策ではなく、鎹（かすがい）です。そう、他に選択肢がない以上、今はこの方法で解決しているのです。
もし、開発者がこれらの問題を解決する方法をプラットフォームレベルで実装してくれれば、APIターミナルにアクセスする必要はなくなるはずです。結局のところ、いい加減な生活をしているから求められるのではなく、MTと作成されるアプリケーションとの間に本格的なやりとりがないからこそ、求められているのです。そして、繰り返しになりますが、この問題は、選択した外部アプリケーションの開発環境に関係なく存在します。
モニタリングとポーリングについて補足すると、誰もが知っていることではありませんが、ポーリングのたびにDLLがジャマにならないように、フラグを「共有」するためにint[]を持つことができます。DLL内部では，すべて__atomic__としてアクセスする．
しかし、MQL側では、インクリメント/デクリメントがアトミックであり、オプティマイザが値について仮定しないことに依存しなければなりません。
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
本当に良いものを作るには、アトミック(volatile?)属性と適切なプリミティブのセットがあれば十分です。私見では、新しい機構をシステムに組み込むよりも簡単で、既存のDLLプロトコルを変更することもありません。
モニタリングとポーリングについて補足すると、誰もが知っているわけではありませんが、ポーリングのたびにDLLを悩ませるのではなく、フラグを「共有」するためにint[]を作成することができます。DLL内部では，すべて__atomic__としてアクセスする．
しかし、MQL側ではインクリメント/デクリメントがアトミックであり、オプティマイザが値について仮定しないことに依存する必要があります。
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
本当に良いものを作るには、アトミック(volatile?)属性と適切なプリミティブのセットがあれば十分です。私見では、システムに新しい機構を組み込むよりも簡単で、既存のDLLプロトコルを変更することもありません。
マキシム、このソリューションはどのように優れているのですか？結局、フラグの状態を確認するためには、MQLでも定期的に確認する必要があります。つまり、どこを見ても、何かの状態の変化を常に監視していないと、データを拾うタイミングがわからないということがわかったのです。そして、この断片はdll自体に格納され、そこでチェックされるかもしれません - これは私がやっていることです。この例では、フラグの状態を返すためにDLLを暗黙のうちに呼び出しています。