デザイナー
保有情報関数FOPPOSITIONの挙動について（第二弾）
こんばんは。
以前、https://bbs.okasan-online.co.jp/ont/rss/board/?category_id=1&topic_id=489 にてFOPPOSITIONの挙動について質問（相談）させていただきました、デザイナーです。
この時の解決策としては、FOPPOSITIONを取得し終わってから、すなわち「***END***」が横一列に並んだら処理を実行する、と変更しそれでうまくいっていました。
が、新たに問題が発生したのでまた相談させてください。
「***END***」が横一列に並んだらFOPPOSITIONの取得が完了したとみなして、次の処理をする、としていたのですが、この場合で解決できるのは***END***がズレてデコボコになった場合を回避できるのみということに気づきました。
FOPPOSITIONの仕様として、保有が更新された際にやはり一瞬0クリア？されて何も保有していないかのような表示になってしまうようです。（それはほんの一瞬で、すぐに正しい保有情報に更新されます。）
たまたま全ての項目で一瞬0クリアされた場合や本当は更新し終わっていないのに「***END***」が横並びになる場合だと、上記の方法ではFOPPOSITIONが更新された、と判定してしまうことになります。
この場合を避けることはできますでしょうか。皆様の知恵をお借りしたいです。
2021年11月24日
大野 了
デザイナーさん、こんにちは！！
こちらは、FOPPOSITIONで複数項目を取得した場合に、
複数関数が同時に動いて同時に0クリアされるということでしょうか？
例えば、
A1セル：=FOPPOSITION("銘柄コード",A2,"0")
B1セル：=FOPPOSITION("建玉単価",B2,"0")
としていた場合に、A1セルの関数とB1セルの関数が同時に動いて
同時にすべてがゼロクリアされて、同時に***END***が書き込まれたということでしょうかー？
正直、少し考えにくい現象ですが、
もしかしたら何かあるかもしれないので少し考えてみます！！
2021年11月25日
デザイナー
大野さん、こんにちは！
はい、概ねそれで合っています。
その場合で、本当は保有しているはずが、A1セルの関数とB1セルの関数が同時に更新され、同時にゼロクリアされて、同時に***END***が書き込まれたと考えております。
もしかしたらなんらか別の現象が起きたのかもしれないですが、「***END***」が横一列に並んだら、以外の方法でFOPPOSITIONの更新が完全に完了したことを察知したい、と言うのが今回の相談です。
2021年11月25日
大野 了
デザイナーさん、こんにちは！！
なるほどー
了解しましたー！！
ちなみにですが、もし同時にセル関数が動いたとして・・・
1．二つの関数が同時に0クリアされる
(この時は「***END***」がないので横一列はFalse)
2．二つの関数が同時にデータを書き出す
(この時は「***END***」が横一列でTrue となるけど、そもそもENDまでのデータも書き出されているため更新が完了してると判断できる)
ような気がするのですが、どちらの時点で問題が発生してるかわかれますでしょうかー？
多分、１のゼロクリアされているところで誤判断されてるとすれば、
「***END***」がないのに Trueになってるのがおかしいため、その部分をつぶせば直るかもしれません！！
2021年11月25日
デザイナー
大野さん、こんばんは！
もし1が発生したとしたら、おっしゃる通りFalseになるので問題ありません。
おそらく２の場合の派生が発生したと考えています。
「同時にデータが書き出されてはいたけど、書き出しが不十分」言い換えると、「ENDまで表示されたけど、保有しているはずのデータが一瞬ない」という状況が発生した気がしています。
ロジックAでは、ロジックAでのエントリがない場合にのみ発注関数を動かすことにしているのですが、ロジックAですでに1枚保有しているかつ別ロジックBでエントリがあって保有情報が変更された場合に、たまたま同時に中途半端にデータが更新されてロジックAもロジックBも1枚も保有していないよー（ENDは横一列になっている）という状態になって、ロジックAがさらに発注して2枚保有となってしまうケースが起こった次第なんです・・
かなりレアなケースかもしれないですが、この場合にはEND横一列戦法が通用しないのではと思ってまして・・
2021年11月26日
大野 了
デザイナーさん、こんにちは！！
そして返信が遅くなってしまい、大変申し訳ありません。
ご返信に気が付いていませんでした・・・
さて本題ですが、
こちらは・・・
1．現在、建玉を1ポジション保有
2．ロジックAで決済
3．"同時"にロジックBで新規建て
4．FOPPOSITIONの更新処理が実行される
という感じでしょうか？
もしそれでしたら、もともと『1．』で持っていたポジションのデータと
『3．』で新規建てした情報がFOPPOSITIONで混ざってしまうことは、
確かにあるかなーと・・・
この場合は確かにEND横一列戦法は使えないのと、FOPPOSITIONにはCSV項目がないため
対応は厳しそうですね・・・
ロジックAとロジックBが同時に動かないように、
ロジックAが動いた後は、FOPPOSITIONのメモ欄などを確認してポジション情報が安定した後に
ロジックBが動くというロジックを組むしかないと思われます・・・
これは厄介ですね・・・
2021年11月30日
デザイナー
大野さん、こんばんは！
コメントありがとうございます。
やはり、そのような対応をするしかないんでしょうかね・・
できる限り各ロジックは独立させて実装したい気持ちがあるので、もう少し考えてみます。
とは言ってもほとんど起こり得ない事象ではあるので次にまた同じ現象が発生したら考えることにしますね。
（こんなことをしているからいつまで経ってもバグが取り切れないのですがww）
2021年12月03日
大野 了
そうですねー
確実に各ロジックは独立させた方がいいですよねー
自分も９つロジックを動かしているのですが、
各ロジックはシグナルをだすだけで、
そのシグナルを検知して一括してオーダーを出すオーダーマネージャみたいなシステムを作って
運用してます！！
そのオーダーマネージャ内でFOPPOSITIONが安定するのを待機しています。
もともとはネッティング処理のために作ったのですが、
結果、複数のロジックがシグナルを同時に立てても大丈夫なつくりにたまたまなっていたという感じです。
なにはともあれ、何か思いついたら追加で書きたいと思います！！
2021年12月03日