请问on_order函数的返回是查询式的还是事件式的呢？具体来说就是，如果on_timer定时器触发信号计算和下单逻辑，下单的OrderStatus状态如果是PartialFill，那是要自己查询订单的状态才能获取这个状态嘛？还是会定时返回这个状态？
因为如果是AllFill的话很好理解，什么时候成交什么时候就能得到返回的Status，但是如果没能成交，就会在盘口挂着，这样是不是除非我自己查询，否则不会知道是PartialFill、NewReject等？
新手小白，诚心求教，希望路过的佬能解答一下。有任何觉得我说的模糊的地方都可以发帖细问。
都是事件驱动，不是主动查询的。
具体机制在零基础教程里有详细介绍，官网视频区里有
好的好的，谢谢！以及我还有一个问题想问，能否赐教一下？（新的帖子还在审核，这里拉个流量）
1. tbpy的on_init中订阅tick和bar级别的K线为什么最多分别只能订阅20、30个合约的？而不是我查到的“订阅量默认200个合约”？超过这两个数字之后会显示“订阅xxx失败，最大订阅=20/30”？2. 以及订阅tick级数据为啥会显示是在订阅“深度行情数据”？这是我代码中触发的报错（其中关于TODO什么的是我的raise Error，但确实分别最多只能订阅20、30个，而不是100个）。请问这个问题您遇到过吗？（图片加载不出来，内容就是显示订阅数据失败，超过可订阅上限）
on是事件触发机制
也有函数自己轮询
你的理解也没问题
主要看你的需求
即如何维护报撤单
或者说
无论哪种机制
只要还需要处理订单流水
事件或轮询机制都需要设计配套的逻辑
好的好的，谢谢！以及我还有一个问题想问，能否赐教一下？（新的帖子还在审核，这里拉个流量）
1. tbpy的on_init中订阅tick和bar级别的K线为什么最多分别只能订阅20、30个合约的？而不是我查到的“订阅量默认200个合约”？超过这两个数字之后会显示“订阅xxx失败，最大订阅=20/30”？2. 以及订阅tick级数据为啥会显示是在订阅“深度行情数据”？这是我代码中触发的报错（其中关于TODO什么的是我的raise Error，但确实分别最多只能订阅20、30个，而不是100个）。请问这个问题您遇到过吗？