mql4でOnTradeTransaction()の代わりになるものは何ですか? - ページ 3

 
Igor Makanu:

もし、迅速な解決策が必要なら、すべてのチケットをCArrayIntに配置し、オープンオーダーのチケットをCArrayIntと比較します。Search()メソッドがあり、チケットがなければ、CArrayIntの比較を停止します。オープンオーダーのカウンターで、CArrayIntをリセットし、すべてのチケットをCArrayIntに再度書き込み、グローバルに記述されたフラグMyOnTradeTransactionを設定します - これはオーダーリストが変更されたというサインです - コードは非常にコンパクトになります。

そして、オーダーロス以上に何かをキャッチする必要があるとき、それはダイヤモンドで踊り始めるとき......。

OrdersTotal()をチェックしても、例えば保留中の注文が有効になったことは表示されません。注文数は 変わらず、チケットも同じです。そして、オーダー/ポジション変更の事実をキャッチする必要があるとき......。

しかし、すべてはすでに考え抜かれ、実行され、説明付きで公開されている......。

 
Alexey Viktorov:

私が否定しているプラスαは何なのでしょうか?否定するのは1つだけです。私は何かの仕組みを理解したいのですが、それが自分の頭以外の人にしか理解できないのであれば、それを使うのは気が引けますし、気が引けるものは否定してしまうのです。もう、一生かかっても読み切れないほどの手紙を書くって言ったじゃないですか。八つ当たりはやめてくれよ...。

長所は、イベントが紛失することがないことです。OnTrade()およびOnTradeTransaction() とは異なります。でも、まさかそんなことが起こるとは......。だ から、議論は無意味だと言っている んです。

 
Artyom Trishkin:

そして、欠番以上の何かをキャッチする必要があるとき、そこからタンバリンが始まる...。

OrdersTotal()をチェックしても、例えば保留中の注文の有効化は表示されません。注文 数は一定で、チケットも、、、。そして、注文やポジションの変更をキャッチする必要があるとき......。

しかし、すべてはすでに考え抜かれ、実行され、解説付きで自由に利用できるようになっている......。

私はOrdersTotalを分析することをお勧めしません、それは信頼性がありません。

その方法では、オーダーの変更を追跡することができません。CArrayまたはCObjをベースにした独自のクラスを書く必要があります。

私は根本的な解決策ではなく、迅速な解決策を提案しました ;)

アルチョム・トリシキン

プラスアルファは、イベントがなくならないことです。

は、PCのリセットボタンを押すと......。長い間、記事を追っていなかったのですが、端末の再起動に備えてクラスの状態をファイルに 保存する手法について質問した記憶があるのですが、これは実装されて いるのでしょうか?
 
Igor Makanu:

OrdersTotalを分析することはお勧めしません、それは信頼性がありません

注文の変更はこの方法では追跡できないので、CArray または CObj をベースにした独自のクラスを作成する必要があります。

根本的な作業ではなく、速やかな解決策を提案しました)

PCのリセットボタンを押せば可能です。長い間記事を追っていなかったのですが、端末の再起動に備えてクラスの状態をファイルに 保存する手法について質問した記憶があるのですが、これはすでに実装されているのでしょうか?

また、バルコニーからコンピュータを投げることも可能です。)そして、ローラーを下で待たせておく。そうすれば、上からコンクリートを流し込むことも可能です :)))

いや、実装されていないんですよ......今はメインじゃないんです。もうすぐ終わりですね。時間を区切ってやるより、全部同じように一度にやったほうが楽です。私の場合。

 
Artyom Trishkin:

いいえ、実装されていません。今はそれがメインではありません。もうすぐ終わりなんですね。同じ種類のものは、時間帯を分けてやるより、一度に全部やったほうが楽です。私の場合。

よーし、待とう

しかし、私は反対であることが判明している - 私はすでにこの問題に遭遇した - 私は、プログラム構造に保存する機能を入れていない、とファイルに保存を書き始めた、非常に面倒なすべてが判明している...。ファイルへの保存をプログラム構成に入れなかった - ファイルへの保存を書き始めたら、非常に面倒なことが判明した - あきらめて、もう一度ゼロからコードの大半を書き直した - イミホ、ファイルへの保存をしたい場合は、少なくとも「スタブ」ですぐに実装しなければなりません。そうしないと、各クラスで保存したいものをすべて集めなければなりません - 非常に面倒な作業、実際、ソースコード全体を分析しなければならないでしょう

 
fxsaber:

何か再現性のある例(取引履歴の調査なし)を提示していただけるとありがたいです。

ご恩に報いることができれば幸いです。私は残念ながら、非常に大規模で複雑なコードから短い動作コードを鍛え上げることに苦労しています。また、非常に特殊です(例えば、一度に1つのポーズしか開けない)。

そのため、Slavaのために、コンパイル可能なサンプルではなく、コードのスケルトンを掲載する必要がありました。

でも、何とかしないと良心の呵責にさいなまれる。でも、すぐには無理です。

追記:コードを書く生産性が非常に低いということです。執念で取るだけです。そして同時に、できるだけ早くEAを実際の口座で 稼働させるために、超多忙な日々を送っています。その生産性がうらやましい。

 
Igor Makanu:

よーし、待とう

しかし、私は反対であることが判明している - 私はすでにこの問題に遭遇した - 私は、プログラム構造に保存する機能を入れていない、とファイルに保存を書き始めた、非常に面倒なすべてが判明している...。ファイルへの保存をプログラム構成に入れず、ファイルへの保存を書き始めたら、非常に面倒なことが判明し、諦めてまた一からコードの大半を書き直しました。ファイルへの保存を計画しているなら、少なくとも「スタブ」ですぐに実装しなければなりません。そうしないと、各クラスで保存したいものをすべて集めなければならず、非常に手間のかかる作業で、実際にはソースコード全体を分析しなければなりません。

save/loadメソッドを初期に宣言する。そして、標準ライブラリの ベースオブジェクトCObjectに。ライブラリの各オブジェクトにおけるファイルへの保存の実装は、1つまたは2つのオブジェクトについて記述することができます。しかし、各記事に保存/ロードの方法の説明を書くことは - むしろ記事から記事へ実質的に同じ "アクション "を読んで退屈になり、単に省略する - 読者に親切ではありません(ので、一部の人々は、彼らが記事のようなボリュームを読むために困難であると言う、私は思います - あまりにもあなた)。したがって - 2つまたは3つの記事で説明するためのこのタスクは、終わりに近い - 一撃で一度に、あまりにも読者に負担をかけません。

もうひとつは、もし記事に何も書かれていなかったら......もちろん、すぐにでも必要なのでしょう。すべては、物語の仕様と目標によります。目的が「コドバザ」なら一気に、目的が「トレーニング用品」なら徐々に、時期が来れば。2つ目の選択肢を用意した。

 
Ihor Herasko:

OnTradeTransactionについては、再度言及されています。接続が切れた場合などでも、接続が回復すれば端末が取引環境を同期させるため、OnTradeTransactionを 保証することに問題はありません。OnTradeはセカンダリー なので、頼りになるということですね。開発者自身が間違えたのではなく、その条項を削除したのであれば、すべてOKということになります。

 
Artyom Trishkin:

しかし、各記事に保存/ロード方法の説明に合わせて - むしろ記事から記事へほぼ同じ "アクション "を読んで退屈になり、ちょうど省略 - 読者に優しくないです(ので、いくつかの彼らは記事のようなボリュームを読んで困難を持っていると言う、私は思う - あなたも)。そのため、-2、3回の記事で記述するためのこのタスクは、最後に近い-一挙に、読者に負担をかけすぎないようにしました。

読むべき記事の量が非常に多いとは言っていないが、ソースの量が膨大で、何らかのヘルプ/FAQがないと使い方がわからないと書いたのである

このような大量のデータを保存する実装を待ちたいと思います、どのような形になるのか興味深いです

 
Igor Makanu:

これだけのデータを保存するための実装は、これからが本番です。

大丈夫