ラベル A2.MT4用EA開発時代 の投稿を表示しています。 すべての投稿を表示
ラベル A2.MT4用EA開発時代 の投稿を表示しています。 すべての投稿を表示

2012/10/26

製品化「MT4用EA作成・運用ソフト」のお知らせ・御礼など



「MT4EA作成・運用ソフト」製品化等のお知らせと御礼です。(Twitterでのお知らせと重複)
#前回ブログ記事の続きを、数十分後に投稿予定です。

この度、当ブログで公開していました「MT4関連ソフト」2種類(「MT4用EA開発用共通部品『ahfw』」・「MT4障害監視システム『ahfw_hc』」)が製品化されました。「お試し版」を無料ダウンロードできますので、ご利用いただければ幸いです。

また今回の開発は、当方ブログやTwitter等を通して、皆様からのご指導・ご支援が無ければ成しえなかったと思います。失礼とは思いますが、この場をお借りして、皆様に御礼申し上げます。

詳細は以下の通りですが、今後とも、よろしくお願いいたします。

 
【お知らせ詳細】
----------------
1.製品化されたMT4関連ソフトウェアについて
  
  公式サイト:http://www.comffered.com/
  
  どちらの製品も、「無料お試し版」をダウンロードできます。
  ※「無料お試し版」での主な制約は、ライブ口座で動作しない点です。
  

   → 「COMFFERED MT4 EA Framework」として製品化しました。

   メタトレーダー4(MT4)の「自動売買プログラム(EA)」作成用ソフトウェア製品です。
    

   → 「COMFFERED MT4 EA Health Checker」として製品化しました。

   MT4を監視し、メールでの異常通知や、障害復旧を試行するソフトウェア製品です。

2.無料ソフトウェア・ダウンロードサイトを変更
  
  新ダウンロード・ページ:http://www.comffered.com/freeware
  
  ●対象

3.製品関連ページ及びアカウント

  公式HP  : http://www.comffered.com/
  Twitter    : http://twitter.com/COMFFERED
  Google+  : http://gplus.to/comffered
  Facebook : http://www.facebook.com/COMFFERED

  従来のTwitterアカウント(@ahaha_fxtrader)は、利用継続いたします。

4.ブログタイトルを変更しました
  「だから何?」という事は・・・
----------------




それでは、
次に投稿される通常ブログ記事も併せて、




今後ともよろしくお願いします!



2012/01/23

MT4用EA開発時代 - MT4のバグとOrderSelectの内部動作妄想



さて前回は、トレーディング・プランの見直しをして、ついに本番開始したところまで書きました。今回は、MT4用EAを開発中に見つけたMT4のバグとOrderSelect動作の妄想について書いてみたいと思います。

今までブログ記事にしてなかったけどMT4用共通部品で対処や検討した点が幾つか。せっかくなので認識してるMT4の問題は一旦吐き出しておこうかと。

【今回のテーマ】
------------------------
1.オーダ操作関数から不正なエラーコード返却
2.OrderSelect()について
  ・期待していたMT4内部動作が外れていて障害発生
  ・OrderSelect()内部動作妄想
------------------------

という事で一つづつ。

【オーダ操作関数から不正なエラーコード返却】
-----------------------------
1.OrderModify()で「ERR_INVALID_TICKETが返却が返却される
  ログに出力していたチケット番号は、口座履歴に存在していて、SL決済されている事を確認済み。
  
  本来であれば、トレードサーバで検出されるべき状況なので、
  「ERR_INVALID_TRADE_PARAMETERS」が返却されるのが正しいはず。
  
  推測だけど、OrderSelect()用の内部メモリテーブルが未完成の状態で、指定したチケット番号
  がどちらにもなかったのが原因なのではないかと思う。※後述
  Build406で発生。
  
2.OrderSend()で「ERR_NO_RESULT」が返却される
  「ERR_NO_RESULT」はOrderModify()の時だけに返却されるエラーコード。
  PC過負荷+NW過負荷の状態で発生。
  実は発注成功しているケースがあり、失敗したと思ってリトライすると
  不要オーダ発生になるので注意。
  Build225/Build229/Build406で発生。
  
  ●参考
  
3.OrderSend()/OrderModify()/OrderClose()で「ERR_COMMON_ERROR」
  PC過負荷+NW過負荷状態なのでバグというかは微妙。
  但し、OrderSend()では上記「2.」と同じ様に実は発注成功しているケースが
  あった。これについてはMT4ヘルプの記載漏れだと思う。
  雰囲気的に通信エラーで発生するっぽく感じた。
  
4.マーケットが閉じた時に「ERR_TRADE_DISABLED」が返却される。
  「ODL Japan」の場合のみ発生。
  デモ口座用のトレードサーバ側の運用の都合かもしれないけど、本来であれば、
  「ERR_MARKET_CLOSED」が返却されるべき。
-----------------------------

さて「OrderSelect()」問題。
今回新たな障害が発生。OrderSelect()挙動による動作不正を回避するために、あるMT4内部動作を前提としていたけど違ったみたいだから修正したという話。

【発生事象】
-------------------------
以下の記事内の、「ERR_INVALID_TRADE_PARAMETERS発生条件-4」のパターンが発生。
そして、「OrderSelect()の結果が最新化されるのはティックデータ受信後のRefreshRates()後」という想定でロジックを組んでいたけど、見事期待が外れて、クリティカル・エラーが発生。


●発生条件と考察(再掲)
下図の「トレードサーバ」側からの2回目のティックデータ送信をMT4クライアント側で受信するタイミングがずれて、「MT4クライアント側」の1回目のRefreshRates()実施後になってしまった場合。

・実際とは異なった前提としたMT4内部動作仮説
以下のいづれか(もしくは両方)が違うという事。
・
OrderSelect()の結果が最新化されるのが、ティックデータ受信後のRefreshRates()後
・OrderModify()のレスポンスをMT4クライアント側が受信した時に、TimeCurrent()が更新される

・前提とした仮説が違っていた場合の方針
「これでダメなら、後はTimeCurrent()が何秒ずれるまで待つ、という設定を追加するか、クリティカルエラーをあきらめて、警告レベルのエラー扱いにするかぐらいしか思いつかない。」

という事で、前回のMT4用EA共通部品リリースでは警告レベルのエラーとして扱う事にした。
-------------------------

そういや過去の開発経緯を見ると、OrderSelectに振り回されてきた。

【「OrderSelect」に関するブログ記事】
-------------------------
-------------------------

これらの動きを総合すると、OrderSelect()の動作は以下の雰囲気になるのではないかと。

【OrderSelect()動作概略の妄想】
--------------------
1.OrderSelect()でのデータ取得元はクライアント上のメモリデータ
2.該当メモリデータは、「取引一覧」と「履歴一覧」の2つに分かれている。
  排他制御も「取引一覧」と「履歴一覧」は別々に制御。
3.サーバ側での情報変化をクライアント側のメモリデータに反映するタイミングは、
  何かのオーダ操作やティックデータ受信時等の他動作の延長線上で更新されるのではない。
  一定間隔等、他動作と同期をとらずにメモリデータが更新される。
4.メモリデータ更新中は排他制御に隙間があり、更新中にOrderSelect()すると
  不定な結果になるケースがある。
5.サーバ側動作の結果、オーダが「取引一覧」から「履歴一覧」に移動する際、
  該当オーダ情報が一旦どちらのテーブルにも無いタイミングが存在する。
6.通信障害があると「履歴一覧」は不完全になるケースがある
--------------------

これを絵にしてみるとこんなイメージ。

【SL/TP決済時の「OrderSelect」イメージ】
--------------------
OrderSelect()用テーブルの状態遷移イメージを書いてみた。

状態1.いくつかの決済済みオーダと保有中オーダがある状態
    左の点線で囲った「取引一覧」は、OrderSelect(MODE_TRADES)で取得されるデータ群。
    右の点線で囲った「履歴一覧」は、OrderSelect(MODE_HISTORY)で取得されるデータ群。
    排他制御は「取引一覧」と「履歴一覧」それぞれ別個に実施されている。
    

状態2.サーバ側でオーダが決済された事を何らかのタイミングで検出
    ここが一番状態として不安定な状態。
    ・「保有中オーダ5」がSL/TP等により決済された旨をサーバ側から受信した後の処理。
     このオーダがどちらのテーブルにも属していない状態。つまりOrderSelect(BY_TICKET)でも
     「保有中オーダ5」が見つからない状態になる。
    ・この「保有中オーダ5」を「取引一覧」から切り離す処理をしている間に、OrderSelect()
     ループを行った時に色々不整合が発生しそう。
    ・本来であれば、図中の「①切り離し」を処理中は「取引一覧」をロックしていると思う。
     OrderSelect()で「取引一覧」からデータを読み込む時も「取引一覧」をロックすべき
     なんだけど、実はしていないんじゃないかという妄想。なので不整合が発生しうる。
    ・もしOrderSelect()実行時に排他制御しているのであれば、エラーが発生しうるはず。
     エラー発生時はGetLastError()にエラーコードが設定されるはずだけど、OrderSelect()は
     エラーコードが設定されない仕様。
    ・「取引一覧」から該当情報を切り離した後、サーバから「保有中オーダ5」の最新情報を
      取得する際、通信障害等によりデータ取得失敗した場合、「履歴一覧」に「保有中オーダ5」
      の情報が追加されない。
    

状態3.オーダが決済された事が完全にMT4クライアントに反映された
      この状態になれば安定する。
    --------------------

こういうツクリであれば、今まで発生した事象のほとんどで辻褄があう気がする。
で、もしこれが事実であれば、明らかにMT4の設計ミス。
もしMT4を修正するのであれば、以下の様な大幅な修正が必要になってしまうので、修正される可能性は低い(と思う)。

という事で、無駄とはわかりつつもMT4修正案を考えてみたw 

【仮説が正しかった場合のMT4設計修正案】
--------------------
1.オーダを「取引一覧」から切り離して、データ最新化後「履歴一覧」に繋ぎ直すのであれば、
  排他制御の単位は、「取引一覧」と「履歴一覧」の両方を対象にしないと必ず隙間ができる。
2.OrderSelect()する際は、「取引一覧」と「履歴一覧」の両方をロックしてから実行しないとやはり隙間
  が発生して不整合が起きる。
3.この両方のテーブルを最新化するAPIが必要。そうでないとサーバからエラー応答がされた時に、
  クライアントとサーバ側の不整合に起因したエラーなのか、EAバグ起因なのかが区別できない。
--------------------




さて、どうでしょう????

あくまでも妄想です。。
実際どうなのかを、ご存知の方おられたら教えて欲しいです。。


そして、「FXシステムトレード初心者奮闘記」は、本番開始前に実施したMT4用EA実行環境構築について進むのでした。
#今ライブ口座で動作中のEA君は当初資金から0.87%減少。。

2011/12/27

MT4用EA開発時代 - MT4用EA共通部品「ahfw」/MT4障害監視システム「ahfw_hc」バージョンアップのお知らせ



さて前回は、2009年/2010年のパフォーマンス評価結果と、トレード対象にする通貨ペア選定方法の検討について書きました。
今回は、今までブログ更新せずに何をやっていたのかという話と、MT4用EAのテストが全て完了したので、MT4用の2つの共通部品の正式版リリースの案内です。


1ヶ月以上もブログ更新が空いてしまった。。。。
一体、今まで何をしてたかというと、


禁煙治療。



ちゃうちゃう。それもあるけど、以下の様な感じ。

【前回ブログ投稿時からの作業】
--------------------------
1.当初予定通りのMT4用EA本番開始に向けたEAテスト
  過負荷試験、障害試験等
2.上記に付随したNW切替の仕組みや、環境整備
3.FXライブ口座開設/入金
4.スマホ導入(トレード用PCへのリモートアクセス目的)
5.予備用ISP開設/環境設定
6.新トレードルールの多市場多期間検証
--------------------------

以前ブログで書いた作業スケジュールを抜粋すると以下の通りで、ほぼスケジュール通りに進めてる感じ。

【当初予定のスケジュール】(再掲)
-------------------------
-------------------------

実際やってみると、上記「2.」のISP障害時のNW自動切換えに以外と時間がかかったのと、「6.新トレードルールの多市場多期間検証」でつい、いろんな事を試してしまった。

そして試験も全部終わり、MT4用EA開発用共通部品「ahfw」と、MT4障害監視システム「ahfw_hc」で見つかったバグも全て修正したので、今回は試験を全て終了させた正式版としての初リリースというお知らせです。

試験の中でわかった色んな事や、色々工夫した点とかの情報は別途順次投稿していきます。まずは2012年1月の本番開始が最優先!!


という事でリリースのお知らせです。


【MT4用EA開発共通部品「ahfw」正式版バージョンアップリリース】
--------------------------------------
1.今回の修正内容
  ・障害や過負荷状態時に顕在化したレアケースへの対応。
  ・運用性の改善
  ※詳細はダウンロードページに記載しています
2.ダウンロードページ
  以下のブログページからダウンロードしてください。
  #今回は正式版1.06です。
  
--------------------------------------

【MT4障害監視システム「ahfw_hc」正式版バージョンアップリリース】
--------------------------------------
1.今回の修正内容
  ・不要なメール通知やメッセージ表示が発生してしまうバグを修正。
  ・運用性の改善
  ※詳細はダウンロードページに記載しています
2.ダウンロードページ
  以下のブログページからダウンロードしてください。
  #今回正式版1.04です。
  
  
--------------------------------------

さて、EAが完成したところで、今後の予定を整理してみた。

【今後の予定】
--------------------------------------
1.最適化方式見直しによるパラメータ選定ロジックの変更
  今DBを使って、最適化後のパラメータを計算するロジックを
  書いているけど、以前の記事で最適化の目的関数とか対象通貨ペア変更
  に伴って、SQLの変更とかパラメータ変更とかが必要。
2.実際に最適化後のパラメータ値を求める
  新最適化方式だと今取得可能なデータでスキャンが可能な通貨ペアあり
  当初4通貨ペアだったけど、見直しの結果6通貨ペアに。
  スキャンはそれなりに時間がかかるので、最適化できる通貨ペアは
  先に最適化してパラメータを求めておきたい。
3.トレードルール見直し
  あと1つだけルール見直し案を試していないので、できればそれを
  試してみたい。
4.トレーディング・プラン再作成
  最適化方式とトレード対象通貨ペアを変更したので、トレーディング・
  プランを見直して整理したい。
--------------------------------------



うーん。。。。
意外とてんこ盛り。。。。




そして、結構空いたにも関わらずあっさりした内容で「FXシステムトレード初心者奮闘記」は、プラン作成か、トレードルール変更評価か、総合テスト中のハプニングに続くのでした。
#禁煙治療は内服治療期間も終了! 禁煙すると集中力が落ちた気がする。。。

2011/09/15

MT4用EA開発時代 - MT4用EA共通部品「ahfw」/MT4障害監視システム「ahfw_hc」バージョンアップと今後の予定



さて前回は、MT4用共通部品「ahfw」/MT4障害監視システム「ahfw_hc」の設計書レビューとソースコードレビュー結果反映版のバージョンアップリリースと、OrderSelectのバグを見つけた話をしました。今回は、機能テスト完了したので再度バージョンアップのお知らせと、今後の予定等について書いてみたいと思います。

【今回のお題】
----------------------
1.テスト状況について
2.MT4用EA共通部品「ahfw」バージョンアップリリースのお知らせ
3.MT4障害監視システム「ahfw_hc」バージョンアップリリースのお知らせ
4.今後の予定
  前倒し作業と、追加で最適化とかトレードルールの改善とか。
5.もしかして「OrderSelect問題」の原因は。。。
----------------------

【テスト状況について】
-------------------------------
さて前回のブログ記事からだいぶ日がたっちゃいましたが、その間粛々と9月の予定である、機能テストを実施してました。前回のリリースでは48件のバグ/改善項目があったんだけど、今回の機能テストでは16件のバグ/改善項目を摘出!


バグが収束傾向にあるからいい感じ!!


さて、残ってた8月分作業と、9月に予定していた作業は以下の4点。

●完了した8月の残作業
 1.トレード用PCクリアインストール
 2.最新Buildにバージョンアップ
●完了した9月の作業
 1.AUDUSDの再最適化
 2.機能テスト実施

もともと9月一杯かかるかなと思ってたのもまで含めて、早くも全て終了!!


手を抜いたんじゃないか?と思ってる方、







正解!




実は網羅性はある程度キープしつつも、バリエーションは思いっきり減らして、テスト項目数を減らしました。。。



でも、今までずっと4つのデモ環境で必要以上にEAを動かしていて、そのログ精査をずっとしていた。そして、そのログ精査方法はトレードサーバからのエラーコードを主軸に見ていた。でも、もう出尽くした感じになっちゃったので、ログを精査する範囲を広げてEA動作の正常性を確認する様に。

もう一つ、元々予定していた「AUDUSDの再最適化」の実施。

これで機能テスト以外にも、都合バグ2件摘出できたので、やってよかった!!

という事で、無事9月分の作業予定も終って、開発の山場は乗り越えた感じになった~
----------------------------------

という事でリリースのお知らせです!

【MT4用EA開発共通部品「ahfw」ベータ版バージョンアップリリース】
--------------------------------------
1.今回の修正内容
以下はプログラムに修正が発生した10件。他の6件は設計書誤り。
  ●設計変更/改善
   ・証拠金観点で発注失敗した際、クリティカルエラーとして該当EA+通貨ペアを発注禁止状態
    にしていたが、警告レベルのエラーに変更。発注可能な証拠金の状態となり、発注に成功
    した場合は、その旨もメール通知する様に変更。
  ●重要度-大
   ・GetMaxLotSize()で証拠金維持率の計算式が間違えていたのを修正
  ●重要度-中
   ・CalcLotSize()の第一引数が不正な場合に、-1が返却されないバグを修正
   ・CheckLotSize()の第一引数が不正の場合、FALSEを返却していないバグを修正
   ・EAをチャートから削除しても大域変数の"FW_ThreadStartTime" が残ってしまうバグを修正
   ・トレードログで、オーダ保有中にプロパティ変更したら、変更後のプロパティが出力
    されるバグを修正(ユーザーズガイドも併せて修正)
  ●重要度-小
   ・提供テンプレートでEAToOrder()のロット数を求めるコメントアウトしたロジックの、vCmdとすべき
    箇所がcmdになっているバグを修正
   ・FWModifyOrderでSLが凍結レベルにある場合でSL補正された場合に毎回ログ出力
    されるバグを修正
   ・FWModifyOrderでSL補正されてなくても、補正した旨の運用ログが出力される事があるバグを修正
2.ダウンロードページ
  以下のブログページからダウンロードしてください。
  #今回はベータ版1.05です。
  
  
--------------------------------------

【MT4障害監視システム「ahfw_hc」ベータ版バージョンアップリリース】
--------------------------------------
1.今回の修正内容
  ・MT4再起動リトライアウト時にその旨のメールが送信されない事がある
   バグを修正
2.ダウンロードページ
  以下のブログページからダウンロードしてください。
  #今回はベータ版1.03です。
  
  
--------------------------------------


そして山場を超え、今後の予定!


【今後の予定】
--------------------------------
さて開発も前倒しで山場を無事に超え、多分MT4用EA共通部品開発作業も落ち着くので、今後の予定を見直そうかと。

もともと10月の予定としては、「障害試験」/「過負荷試験」だけだったんだけど、実際問題1回そういう状況を作ってしまえば長時間流してる事に意味があるのであって、作業自体は少ない。

なので、一部作業の前倒しと追加でやりたい事を纏めてみた。

1.スマートフォンによる外部からトレード用PCへのアクセステスト
  「TeamViwer」というソフトを使えばできるっぽいけど、不安定という話も小耳に挟む。
  人によってはPCを道連れにお亡くなりになる事例もあるので、早めに評価を試したい。
  なので、11月評価開始予定を10月開始もしくは9月下旬からの開始に前倒しする。
  
  決して、早くスマフォが欲しいからではありません。。
  
#「きっとスマフォが欲しいだけだ」とヨメが。。。 
  
2.最適化方法の見直し
  きっかけはPhaiさんのブログ「FXシステムトレード研究ノート~上級者用~」で考案されてた、
  「フォワードテストと再現性指数」という記事の内容。
  

  もうこの記事の内容が、わしの心を掴んで離しません!

  
  該当ブログ記事とはちょっと異なる目的だけど、この手法を使ってウォークフォワード分析で、
  最適化目的関数と最適化期間/ウォークフォワード期間の妥当性について再度検証して
  みようかと。
  
  今まで1回のフォワードテストでは最適化期間のベストのパラメータセット1つだけが評価対象
  だったけど、この方法を使えばスキャン数である100個のパラメータセットを総合的
  に評価できる様になるので、より信憑性のある評価になるのではないかと。
  
  今までのウォークフォワード分析でのWF効率を期間毎に見た場合、ばらばらすぎて評価に
  値しない状況だったけど、前述のブログで登場する手法を使えば期間毎のばらつき具合を
  もっと客観的に評価できるんじゃないかと。
  
3.トレードルールの見直し
  今更ですか?という話しはあるんですけど、ちょっと試して見たい事がでてきた。
  つい先日行って来たセミナーの中で、シストレのメリットの一つとして、
  「トレード状況を客観的に見れる」という点があったけど、まさにそれ。
  
  デモ口座で本番想定の設定で動かしている環境が一つあって、それをずっと眺めてた。
  
  それで気になったのが、急激な値動きに弱いという点。
  
  なので、時間が間に合えば、今使ってるSMAをWMAかEMAに変更してみて
  評価してみようと。
--------------------------------

そして、ちょっとした小ネタ

【もしかしてOrderSelect問題の原因は。。。】
--------------------------------
かねてから根本原因がわからず、start()関数を排他制御することで問題回避していた、「OrderSelect問題」。該当事象が発生してて口座開設予定の「FOREX.com」のサイトを見てるとこんな事が書いてた。


 【Expert Advisors(EA) 使用時の注意点 2011/7/20 19:04】 
 MetaTrader4の取引口座内において、誤約定・誤作動が発生いたしました。システムを正常稼働
 させるためEA使用時は、以下の点をお控いただきますようお願いいたします。
 1.同一取引口座内にて複数のEAプログラム使用・運用。(EA使用の場合、1取引口座、1EAの
   使用・運用をお願いいたします。)
 2.残高不足状況下において、EAのセット。(一旦ログオフし、EAプログラムの確認および証拠金
   を確認してからの運用をお願いいたします。)

特に問題は、上記「1.」の部分。

他のMT4対応FX業者ではこんな制限無いよね???
#気付いてないだけという話もある様な気がするけど。。

勘でしかないけど、「OrderSelect問題」の原因はココにあるんじゃないかと。。
そもそも1EAといってるけど、1EAの定義がわからん。
つまり、1つのMAGICナンバーと言ってるのか、1つチャート上だけでEAを動かせと言ってるのか不明。

最終形として想定してる、3種類のEA×4通貨ペアだと12口座開けと???






ありえへん。。



問い合わせてみよ。。。

★★2011/9/15 15:08追記
★★
問い合わせの結果、以下の回答がありました。対応が早かった!
A:現在においては同一取引口座内にて複数のEAを使用していただくことは問題ありません。但し個々のプログラムに依存することもありデモ環境等を使っての確認をお願いしております。なお残高不足状況下においてのEAのセットに関しましては引き続きご使用をお控えいただくことをお願いしております。(発注されない注文となるため) --------------------------------






という事で、「MT4用EA開発時代」は一旦終了!!
#バグとか発見があれば、また記事にします。




そして「MT4用EA開発時代」は一旦終了し、「FXシステムトレード初心者奮闘記」は「初本番に向けて」に進むのでした。
#実はBuild402にしたらPublisher機能が途中で止まるという事象が発生する様に。。。

2011/08/27

MT4用EA開発時代 - MT4用EA共通部品「ahfw」/MT4障害監視システム「ahfw_hc」バージョンアップとMT4バグ



さて前回は、EA無言停止対策とデモ口座期限切れ対策の考慮漏れについて検討している様子を書きました。今回は、MT4用EA共通部品「ahfw」/MT4障害監視システム「ahfw_hc」のバージョンアップリリースとリリースにいたるまでの諸々について書いてみたいと思います。

【本日のお題】
-----------------------
1.テスト状況について
2.OrderDelete()後のOrderSelect(SELECT_BY_TICKET)について
  多分MT4をバグ発見
3.MT4用EA共通部品「ahfw」バージョンアップリリースのお知らせ
4.MT4障害監視システム「ahfw_hc」バージョンアップリリースのお知らせ
-----------------------


【テスト状況について】
-----------------------------
さて、以前のテスト計画で決めてた8月末期限ですることを振り返ると、以下の様な感じ。

●8月の作業予定
 1.設計書レビュー
 2.プログラムソースレビュー
 3.PC切替テスト
 4.トレード用PCクリアインストール
 5.最新Buildへのバージョンアップ

以前の記事では、上記「1.」のネタである設計書を書いただけで発見したバグを修正した
話で、上記「1.」自体はまだだった状態。

今回無事に、「3.PC切替テスト」まで完了しました~



わ~い!! パチパチパチ!!!


と、一人で盛り上がってますが、前述の「1.設計書レビュー」と「2.プログラムソースレビュー」
で見つかるわ見つかるわ、たくさんのバグたち。

●見つかったバグ
 1.設計バグ
   ・CalcLotSize()でエラー検出時にゼロを返却しているが-1を返却すべき
   ・GetMaxLotSize()でエラー発生時にゼロを返却しているが-1を返却すべき
 2.重要度-大
   ・EAOnPendingOrderOpened()の呼び出し方が設計書と著しく異なる
   ・EAOnClose()呼出し時に、vCmd , vCondが正しく渡せない事がある
   ・オーダ保有状態取得時(OrderSelectループ)に、決済済みオーダと未決済オーダの両方
    の情報がある場合、保有オーダ無しと判断されるケースがある
   ・大域変数設計変更によるデータ変換処理失敗時に、保有中オーダがあると不正なオーダ
    操作となる可能性がある
   ・決済処理で、発注タイムアウト後の不要オーダ削除失敗後の場合、成功した発注オーダ
    が決済されてしまう
   ・start()処理が一回動いた後、deinit()/init()で処理に時間がかかった場合、スレッド停止障害
    と誤検知される
    可能性がある
   ・トレードログ出力で、不要な判定文があり不要なトレードログが出力される可能性がある
   ・AdjustTpPrice()関数で、ストップレベルによる価格補正が間違い
   ・CheckLotSize()関数で、指定ロットが最大ロット数を超過しており、通知が必要な引数を
    指定されていた場合にメール通知されない
 3.重要度-中
   ・AdjustLotSize()関数ででエラー検出時に引数のロット数変数に-1を設定していない
   ・AdjustSlPrice()/AdjustTpPrice()関数で、現在の価格が凍結レベル内の時、引数の価格変数に
    現在値を設定していない
   ・決済処理でリトライすると、トレードログの決済時のスリッページ出力がずれてしまう
   ・決済処理で凍結レベルが設定されている場合、SL/TP価格が凍結レベル範囲内かどうかの
    判定がおかしい
   ・チャート変更時/EAリコンパイル時に、FWinit()が2回呼び出されてしまう
   ・deinit()での大域変数クリア処理で、FW_StopAllが抜けている
   ・deinit()で呼び出し理由がチャート変更の場合は大域変数削除されていなかった
   ・init()時のアカウント切れの際の大域変数クリアで、FW_StopAllが抜けている
   ・init()時のセマフォキー生成処理でエラー発生時にリトライされているが、リトライは不要
   ・start()関数排他制御処理内のエラー処理が誤まっており、start()でフリーズする可能性がある
   ・SL/TP変更処理時、リトライループ中に決済されていた場合、情報レベルの運用ログが
    出力されない
   ・メール通知や運用ログ出力時のチケット番号が不定になる
   ・決済後処理で、FWOrderCondが不正な値になる
   ・AdjustLotSize()で、ロット数有効桁数を計算するタイミングが、ゼロ除算チェック前
   ・AdjustSlPrice()/AdjustTpPrice()で、エラー検出時に引数の価格変数に-1を設定していない
   ・大域変数の削除漏れ
   ・メールサブジェクトにEA名とMAGICが付与されていない
 4.軽微なバグ/改善
   ・オーダ保有していなかった場合に、コールバック関数に渡すvCmdが不定になる
   ・初期状態ではオーダ保有状態は不明とすべき。デフォルトでORDER_NONEになっている。
   ・テスター開始時の大域変数削除処理で、FW_StopAllが抜けている
   ・EAGetModifyPrice()でSLもTPもゼロ以下の場合に、同じバーで何回もEAGetModifyPrice()が
    呼びだされる
   ・発注前のSL価格と発注価格の上下関係チェックで、補正前の価格が使用されている
   ・発注前のTP価格と発注価格の上下関係チェックで、補正前の価格が使用されている
   ・2バー前の時のEAToOrder()に渡す参照変数をゼロで初期化していない
   ・OnError()関数で引数のvLevelが不正な場合にログ出力されない。
   ・OnError()関数のコメントで説明不足の箇所あり
   ・不要なコメント行やロジックがある
   ・大域変数のセットで、エラー判定は戻り値がゼロで判定すべき
   ・その他軽微な改善

プログラムソースから設計書をおこして、その設計書を元にプログラムソースをレビューで
なんでこんなに見つかるんや?という疑問もあるかもしれないですけど、こういうもんです。。



やっただけの価値があった!!



と素直に喜んでおこう。

今は「4.トレード用PCクリアインストール」に向けた環境構築手順書までは
できて、土日をかけて実施する予定。作業が間に合わなくても、暫定予備PCに切り替えれる
様にしたので、大丈夫!!
-----------------------------

さて、次の話題。

【OrderDelete()後のOrderSelect(SELECT_BY_TICKET)について】
----------------------------------
さて、突如現るプログラミングの各論。一体なんなのかというと、あるバグを修正するのに、
今までうやむやにしていた事をはっきりさせる必要があった事が1点。

それは、OrderDelete()したチケット番号を指定してOrderSelect(SELECT_BY_TICKET)すると、
FALSEが返却され、失敗するという点。

まず、ヘルプを見てみると。

1.OrderSelectヘルプ(非公式有志)の抜粋
  「The function selects an order for further processing. It returns TRUE if the function succeeds. 
   It returns FALSE if the function fails. To get the error information, one has to call the 
   GetLastError() function.
   この関数は、さらに先の処理のためにオーダーを選択します。この関数が正常終了した場合、
   戻り値は TRUE です。この関数が失敗した場合、戻り値は FALSE です。詳細なエラー情報
   を取得するには、GetLastError() を呼び出します。

   The pool parameter is ignored if the order is selected by the ticket number. The ticket number 
   is a unique order identifier. To find out from what list the order has been selected, its close
   time must be analyzed. 
   If the order close time equals to 0, the order is open or pending and taken from the terminal 
   open positions list. One can distinguish an open position from a pending order by the order 
   type. If the order close time 
   does not equal to 0, the order is a closed order or a deleted pending order and was 
   selected from the terminal history. They also differ from each other by their order types.
   もし、オーダーがチケット番号で選ばれる場合、pool パラメータは無視されます。チケット番号は、
   一意のオーダー識別子です。どのリストからオーダーが選択されたかを認識するには、その決済
   時間を調べる必要があります。もし、決済時間が 0 
   ならば、そのオーダーは保有中か待機中で、ターミナルの保有中ポジション一覧からの取得
   されています。注文タイプによって、
   保有中ポジションを保留中オーダーと区別することができます。もし、オーダーの決済時間が 0 
   でない場合、そのオーダーは、決済オーダーか、削除された保留中オーダーで、ターミナルの
   履歴から選択されています。それらは、同じく、それらの注文
   タイプによって異っています。」
  
   ここのポイントは、チケット番号指定の場合は、第三引数のpoolが無視される点と、失敗した
   場合はGetLastError()にエラーコードが設定されるという点。そして、「オーダーの決済時間が 
   0 でない場合、そのオーダーは、決済オーダーか、削除された保留中オーダーで、ターミナルの
   履歴から選択されています。」という記述。

   つまり、削除(OrderDelete())済みもOrderSelect()できるという事。
  
   次に、「ランタイムエラー」(Runtime errors)のヘルプを見てみると。
   
   「Other functions never change the last_error variable value.
    その他の関数は、last_error 変数値を変更することはありません。
    AccountBalance, AccountCompany, ・・・OrderSelect, ・・・・WindowYOnDropped, Year」

   片やエラー情報はGetLastError()で取得せよと書いてあるのに、片やエラー情報は設定され
   ないと書いてある。


   
   
   どっちやねん。
   
   
2.実際に簡単なプログラムで試して見る
  試して見たのは以下のプログラム。

  ●プログラムソース  
int start()
  {
//----
    int ticket = 0;
    Print("Start!!");
    while( TRUE )
    {
        ticket = OrderSend(Symbol(),OP_BUYSTOP,MarketInfo(Symbol(),MODE_MINLOT),Ask+30*Point,10,Bid-(MarketInfo(Symbol(),MODE_STOPLEVEL)+1)*Point,0,NULL,11111111);
        if( ticket <= 0 )
        {
            int errno = GetLastError();
            Print("OrderFailed:errno("+errno+") " + ErrorDescription(errno)+")");
            return(0);
        }
        else
        {
            Print("OrderSuccess("+ticket+")");
            break;
        }
    }
    while(TRUE)
    {
        if( OrderDelete(ticket) )
        {
            if( OrderSelect(ticket , SELECT_BY_TICKET ) )
            {
                Print("OrderSelect was succeed : OrderType("+OrderType()+")");
            }
            else
            {
                int err = GetLastError();
                Print("OrderSelect was failed. : OrderTicket("+OrderTicket()+") OrderType("+OrderType()+") errno("+err+"):"+ErrorDescription(err)+")");
            }
            return;
        }
        continue;
    }
   
//----
   return(0);
  }
●ログの結果
15:36:27 XOrderDelete EURGBPfxf.,M5: Start!!
15:36:41 XOrderDelete EURGBPfxf.,M5: open #6430715 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8837 ok
15:36:41 XOrderDelete EURGBPfxf.,M5: OrderSuccess(6430715)
15:36:43 XOrderDelete EURGBPfxf.,M5: delete #6430715 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8837 tp: 0.0000 ok
15:36:43 stdlib EURGBPfxf.,M5: loaded successfully
15:36:43 XOrderDelete EURGBPfxf.,M5: OrderSelect was failed. : OrderTicket(0) OrderType(0) errno(0):no error)
15:36:44 XOrderDelete EURGBPfxf.,M5: Start!!
15:36:44 XOrderDelete EURGBPfxf.,M5: open #6430716 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8837 ok
15:36:44 XOrderDelete EURGBPfxf.,M5: OrderSuccess(6430716)
15:36:46 XOrderDelete EURGBPfxf.,M5: delete #6430716 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8837 tp: 0.0000 ok
15:36:46 XOrderDelete EURGBPfxf.,M5: OrderSelect was failed. : OrderTicket(0) OrderType(0) errno(0):no error)
15:36:47 XOrderDelete EURGBPfxf.,M5: Start!!
15:36:47 XOrderDelete EURGBPfxf.,M5: open #6430717 buy stop 0.01 EURGBPfxf. at 0.8872 sl: 0.8837 ok
15:36:47 XOrderDelete EURGBPfxf.,M5: OrderSuccess(6430717)
15:36:47 XOrderDelete EURGBPfxf.,M5: delete #6430717 buy stop 0.01 EURGBPfxf. at 0.8872 sl: 0.8837 tp: 0.0000 ok
15:36:47 XOrderDelete EURGBPfxf.,M5: OrderSelect was failed. : OrderTicket(0) OrderType(0) errno(0):no error)
15:36:52 XOrderDelete EURGBPfxf.,M5: Start!!
15:36:52 XOrderDelete EURGBPfxf.,M5: open #6430718 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8836 ok
15:36:52 XOrderDelete EURGBPfxf.,M5: OrderSuccess(6430718)
15:36:53 XOrderDelete EURGBPfxf.,M5: delete #6430718 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8836 tp: 0.0000 ok
15:36:53 XOrderDelete EURGBPfxf.,M5: OrderSelect was failed. : OrderTicket(0) OrderType(0) errno(0):no error)
15:36:54 XOrderDelete EURGBPfxf.,M5: Start!!
15:36:58 XOrderDelete EURGBPfxf.,M5: open #6430719 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8837 ok
15:36:58 XOrderDelete EURGBPfxf.,M5: OrderSuccess(6430719)
15:36:58 XOrderDelete EURGBPfxf.,M5: delete #6430719 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8837 tp: 0.0000 ok
15:36:58 XOrderDelete EURGBPfxf.,M5: OrderSelect was failed. : OrderTicket(0) OrderType(0) errno(0):no error)
15:37:05 XOrderDelete EURGBPfxf.,M5: Start!!
15:37:05 XOrderDelete EURGBPfxf.,M5: open #6430720 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8836 ok
15:37:05 XOrderDelete EURGBPfxf.,M5: OrderSuccess(6430720)
15:37:05 XOrderDelete EURGBPfxf.,M5: delete #6430720 buy stop 0.01 EURGBPfxf. at 0.8871 sl: 0.8836 tp: 0.0000 ok
15:37:05 XOrderDelete EURGBPfxf.,M5: OrderSelect was failed. : OrderTicket(0) OrderType(0) errno(0):no error)
   
   
   やっぱり、OrderSelect()全部失敗してるし、GetLastError()ではエラー情報取得できない。
   ちなみに、OrderSelect()の第三引数に、MODE_HISTORY/MODE_TRADESを指定しても結果は同じ。
  
  
  
  
  MT4のバグやんけ。。。。
  #Forex.com Japan Build229
  
  
  つまり、バグの内容は以下の2点。
  ・OrderDelete()後にチケット番号指定でOrderSelect()できないというバグ
  ・OrderSelect()失敗時のエラー詳細はGetLastErro()で取得できないというヘルプのバグ
  
  SELECT_BY_POSでMODE_HISTORYをループさせたらOrderDelete()済みのチケット番号
  でOrderSelect()できるかもしれないけど、履歴側はオーダがたくさんあるから処理時間結構
  かかりそう。
  
  なので、そういうもんだとあきらめて、別の手段で対処することにした。
----------------------------------------


さて、ついに各バージョンアップリリースのお知らせです。

【MT4用EA開発共通部品「ahfw」ベータ版バージョンアップリリース】
--------------------------------------
1.今回の修正内容
  以下の以前の記事に書いた内容
  ・今回の記事で記載した摘出バグ
  
  今回の目玉は、上記バグ修正/機能追加以外にも、ユーザーズガイドを
  大幅拡充した点。機能の詳細を書いたのでページ数も92ページまで増加。
  
  エラーコード毎のエラー制御処理の一覧だけでも役に立つかな??
  
2.ダウンロードページ
  以下のブログページからダウンロードしてください。
  #今回はベータ版1.04です。
  

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

【MT4障害監視システム「ahfw_hc」ベータ版バージョンアップリリース】
--------------------------------------
1.今回の修正内容
  ・ユーザーズガイド
   わかり易い様に表現を見直し
   「ahfw」を使わない場合にEAでの対応する方法について追記
2.ダウンロードページ
  以下のブログページからダウンロードしてください。
  #今回はベータ版1.02です。
  
  
--------------------------------------





今のところ予定通り!!

オチも無し!!




そして、実は気が重いPCクリアインストールを控えながら、「FXシステムトレード初心者奮闘記」の「MT4用EA開発時代」は、機能試験に進むのでした。
#暫定予備用PCがめっちゃ熱くなっててビックリした。。。