ログブックエントリーの意味するところ - ページ 4

新しいコメント
 
そして、OrderModifyをまだチェックしていない :(
そして、保留中の注文:(
 
というわけで、かなり久しぶりの数日間。この間、何人もの専門家が何とか仕事をこなしてきた。以下はそのログです（このログを生成するコードは上にあります）。せめて開発者からの何らかの返答を待っています。少なくとも、「問題を認めたから、解決しよう」というレベルでは。

ログ1
購入の試行、試行0失敗、エラー6
購入の試行、試行1は失敗、エラー129
購入しようとすると、試行錯誤の結果、エラー129が発生しました。
購入しようとすると、試行錯誤の結果、エラー129が発生しました。
購入しようとすると、試行錯誤の結果、エラー129が発生しました。
ジグザグ買いエラー：4050
2.28000000, 0.02700000, 0.00000000
購入の試行、試行0失敗、エラー6
購入の試み、試行錯誤1回目成功

7回目の挑戦で注文が開きました。途中、何度かエラーメッセージが表示されたが、現実とは関係ない。

ログ2
7.9.2005 11:0:15, Signal: sell7.9.2005 11:0:15 売りを試みる, 試み0.
アスク：1.24820000、ストップロス：0.00600000、テイクプロフィット：0.00000000
失敗、エラー6
7.9.2005 11:0:15 売却を試みる、試行錯誤1。
アスク：1.24820000、ストップロス：0.00600000、テイクプロフィット：0.00000000
旨い

2回目の挑戦で6番目の間違いは、枝分かれして、100以上の投稿がありました。開発者のRoshとComposterのアドバイスにより、エラーの頻度は「たまにある」から「5回に1回程度」に減少しました。でも、まだあるんです。

ログ 3．
ロングポジションを決済しようとしている、チケット：1784257
6.9.2005 12:0:13 このチケットの注文がまだ残っているので、再挑戦する。
6.9.2005 12:0:13 このチケットの注文がまだ残っているので、再挑戦する。
6.9.2005 12:0:13 このチケットの注文がまだ残っているので、再挑戦する。
6.9.2005 12:0:13 このチケットの注文がまだ残っているので、再挑戦する。
6.9.2005 12:0:13 このチケットの注文がまだ残っているので、再挑戦する。

5回失敗したが、エラーコードはなかった。プログラムでは、そのポジションは閉鎖されたと思っていました。ループの中でチケットをキャッチしていた、そうしないと問題が検出されないからだ。

といった具合に。
 
このように作る
<br / translate="no"> void CloseBuy(string strExpertName)
{
int nTicket = OrderTicket();
SaveComment("\rnâtâuAttempting to close long position, ticket: " + nTicket);

int nResult = OrderClose(OrderTicket(), OrderLots(), Bid, nSlip, Aqua);

Sleep(10000)です。

if(nResult == -1)
{
int nError = GetLastError();
Alert(strExpertName + ", error: " + nError)を実行します。
}

}


引用符で文字を太くする必要がありました。
 
この場合、エラーをマスクしてしまう可能性が高いです。そして、開発者がそれを見つけて、ループを全く使わずにすべてが動くようにすることが目標です。

Sleepのポイントは、障害の原因となっている状態がなくなる（Pingが通るようになる）のを待つだけです。なぜなら、貿易業務では、コントロールを「奪い」、戻ってくるまで手放さないことを考慮すると、エラーがあれば、すぐに表示されるはずだからです。そうでなければ、それはバグです。

唯一の例外は、クローズしたばかりのポジションのチケットをチェックする私のループです。しかし、ここでも、システムが理想的にどのように振る舞うべきかを議論することができます。

ここでも問題は、エラーがRETURNEDされるだけでなく、エラーコードが天井から取られていたり、時にはコードが全くない、つまり操作の成功コードが返されることである。

わからないことがあれば、説明してほしい。
 
説明する。あるExpert Advisorの条件では、現在の Ask価格が、保留中の 売り 注文のストップロスを超えた場合、一連のアクションが実行されます。
1.そのような注文を削除する意図を通知するSMSが送信されます。
2.注文のキャンセルの試みが行われる
3.OrderDelete()関数の結果が分析され、それが負であれば（注文は削除されていない）、
4.失敗を確認するSMSを送信します。

昨日、2通のSMSが届きました。すべて規則通りでしたが、ログによると、注文は同じ瞬間にキャンセルされました。
つまり、EAは注文取消操作の結果を 得るより何分の一秒か早く得ようとしていたのです。中国人がジャガイモを植えて、次の日に掘り起こすというジョークにあるようなものです。そんなに熟すのが早いんですか」と聞かれると、「いや、でも食いしん坊なんですよ」と答えます(笑)。
 
理解した、しかし。
1.実際の注文について、このように騒いだのです。そして、もしそのような振る舞いをするのであれば、修正する必要があります。
2) MT EAが遅延サイクルなしで取引できるようにすることです。こうあるべきなのです。
私は遅延を置くが、彼らが言うように、 "喜びなしで" :)
 
と思っていたのですが注文の変更操作とその結果を確認する間に間を置くということは、EAの非同期動作を想定していることになります。これは、注文を修正しようとするリクエストをサーバーに送信し、その後、返事を待つことなく、Expert Advisorがアルゴリズムに従って作業を継続することを意味します。デフォルトでは、Expert Advisorはサーバから返信があるまで否定的な返答をします。 返信がある場合は実返事、ない場合は仮想返事となります。

私自身は信じていないのですが、開発者の方々は私の勘違いを説明していただけますか？
 
コンセンサスが得られている。でも、念のため、一時停止を入れました--。少なくとも、締め切ったばかりの注文のチケットの有無を確認する前に、サーバー上のデータベースにアクセスする可能性があるので、リフレッシュする時間を与える必要があります。間違っていますが :)

恥ずかしいことに、このスレッドには37件の投稿がありますが、開発者からの投稿は1件のみです...。
 
このスレッドで37の開発者投稿が1つしかないのはちょっと違和感が...。

よけいなおせわ
 
なぜすでに生産的な議論を邪魔
するのか
そして、これがその製品です =)。

いくつかのテストを行いました。1つのExpert Advisorがポジションをオープンし、クローズする（交互に買い、売る）。すべてのトレードの 間の最小ポーズ - 10秒

テスト時間（Alpariによる）：02:00 - 09:30 (i.e. 7.5 hours)
OrderSend attempts:996
Successful*:888
Errors**:108

* - 「成功した」試みとは、次のような意味です： orderSendはチケット番号を返し、GetLastErrorは0を返し、オープンポジションは正常に選択されました orderselect。
** - All errors #148 "trade context is busy" - これはSlavaが次のスレッドで尋ねていたことです - 「isTradeAllowedチェックを無効にしたらどうでしょうか？エラーは07:16:46に始まり、まだ積み重なっています）

-------------------------------------------------------------------------------

OrderClose attempts:890
Successful*:736
Errors**: 154

* - "成功した "クローズの試みは、私は次のことを意味します：ordercloseは真を返し、GetLastErrorは0を返し、閉じた位置は正常にmod_historyのorderselectを選択しました。
** - 152エラー#1「エラーなし」、#6と#138(requotes)が1つずつ


捕まった状況は起きなかった。つまり、すべてのクローズドポジションは確かにクローズされたのです。
1234567
新しいコメント