約定の処理もちゃんとしなきゃいけないっぽい |
|
| 証券会社への発注の際に、約定とかの面倒な処理は避けようと考えていたのですが、どうやらそういうわけにもいかないようです。例えば、もし売買シグナルを出すアルゴリズムに問題があって、買い注文を発注してそれが約定する前に決済注文を出してしまった場合、買い注文だけが残されてしまう可能性があります。引け間際では下手をすると意図せずに持ち越してしまって大変な目に遭ってしまいそうです。やっぱり約定のチェックはしないとだめなのかな?UWSCとかを使っている人達はこの問題をどう解決しているんだろう?徳山式みたいな方法だったら時間にかなり余裕ができるので、変な注文が多少あっても何とかなるかも知れませんが。
25日や27日に起こったDDE関連の問題を解決する方法を思いつきました。RSS.exeのほかにもうひとつ、RSSで得た情報をそのまま垂れ流すようなDDEサーバー(例えばExcelとか)を予め用意しておいて、自作アプリの起動時に両方のDDEサーバーを接続し、RSS.exeとの接続がダメになったら予備のDDEサーバーからデータを取得するという方法です。これならば、RSS.exeとの接続がダメになった後の再接続にかかる時間を節約できるので、ログが途切れる心配も少なくなると思います。 最初は単純に別のスレッドでRSS.exeに対してDDEリクエストを送信しようと考えていたのですが、それだとトピックやアイテムが多すぎて実用にならないことがわかってしまったので、こういう方法を考えたというだけのことです(実際にはそれだけではなくて、マルチスレッド化したらイベント送信を要求するところでデッドロックっぽい現象が起こってしまったということもあります。マルチスレッド化していなくてもsynclockを使っただけで不定期に固まるので、ライブラリ側の問題なのかも知れません)。 ただDDEサーバーを今から作るとなると、それはそれで面倒な感じです。それにこれをやったからといってうまく行くとも限らないので。 デバッグ中に、自作アプリを停止させずに変数だけ閲覧することってできないのかな~。とりあえずそれだけあれば何か原因は掴めそうなんだけど。
週末資産=1,008,158 前週比=-148 ↑報告の意味が余り無いけど。
△ ( ・∀・) ゆうらゆらぁ~ (υυ) |ノ
| |
|
7月28日(金) | トラックバック(0) | コメント(0) | 日記 | 管理
|
この記事へのコメント投稿はできない設定になっています |