Keyboard Shortcuts
Likes
Search
updateAccountValue callbacks received but not accountDownloadEnd
|
Hi Everyone,
I'm subscribing to account updates with reqAccountUpdates(True, account_id) and receiving both?updateAccountValue and?accountDownloadEnd on the initial callback; however following that I only receive updateAccountValue?callbacks (every 3 minutes as expected) but with no accountDownloadEnd?callback. I though accountDownloadEnd?callbacks are also provided every 3 minutes, but it appears to not be so?? Anyone understand this behaviour? Thanks in advance... Dave |
开云体育Can anyone help on this one?? Would just like to know if accountDownloadEnd is sent by the API at the end of each (3 min) accountDownload subscription set, or only after the initial request is returned?? I assume it’s the End signal is sent each time (and therefore the problem is actually in my code), but just want to eliminate the possibility that the End signal is not sent each time – the documentation is ambiguous. ? In a similar vein, when orders are executed (or cancelled) is the openOrderEnd/completedOrderEnd callback sent automatically? ? I am trying to monitor live for changes in the orders and account, but my thread events are not being set because the respective End callbacks are not being received. ? Dave ? ? From: [email protected] <[email protected]> On Behalf Of David Walker
Sent: Thursday, 30 June 2022 6:31 PM To: [email protected] Subject: [TWS API] updateAccountValue callbacks received but not accountDownloadEnd ? Hi Everyone, |
|
In general, you should expect one and only one "end" callback for each request call. If the request also subscribes you to future updates, in general, do not expect any additional "end" calls. When your client initially connects and requests (for example) account or order updates, you receive an immediate "current" or "historical" complete snapshot of the relevant data. The end of that complete download is indicated by the corresponding "end" callbacks. From that point on, only incremental updates to the initial download are sent for values that actually change. Since these are incremental, "end" callbacks really make no sense and, consequently, are not sent. Hope that helps, 闯ü谤驳别苍 |
开云体育Excellent, thanks 闯ü谤驳别苍. ?So in terms of live monitoring of account/order updates, a separate thread event object (for the incremental updates) is best. ? Dave ? ? ? From: [email protected] <[email protected]> On Behalf Of 闯ü谤驳别苍 Reinold via groups.io
Sent: Friday, 15 July 2022 11:11 AM To: [email protected] Subject: Re: [TWS API] updateAccountValue callbacks received but not accountDownloadEnd ? In general, you should expect one and only one "end" callback for each request call. If the request also subscribes you to future updates, in general, do not expect any additional "end" calls. When your client initially connects and requests (for example) account or order updates, you receive an immediate "current" or "historical" complete snapshot of the relevant data. The end of that complete download is indicated by the corresponding "end" callbacks. From that point on, only incremental updates to the initial download are sent for values that actually change. Since these are incremental, "end" callbacks really make no sense and, consequently, are not sent. Hope that helps, 闯ü谤驳别苍 |
|
Details depend on your application architecture, your framework(s), and to some degree the programming language you use. In the simplest case you could use a model (as in Model-View-Controller) with read-only fields for the account values you are interested in. Callbacks from the initial request and from ongoing incremental updates simply change the corresponding fields in the model. The various client parts read the most recent value from the model when they need a value. In case you can use "Observable" data objects or some kind of "Data Binding" framework for fields in your model, updates from TWS API callbacks can trigger chains of notifications and method calls in your client. That can work in single-threaded and multi-threaded designs. I assume when you mention "thread event object" you refer to Python. I am not fluent enough in Python to give you concrete advice and "thread event objects" may very well all you need. But there are Python libraries and frameworks available that implement "observable patterns" or more general "data binding" services that may provide more features and more convenient APIs with less programming effort. 闯ü谤驳别苍 |
开云体育Thanks 闯ü谤驳别苍. I wasn’t aware of observable data objects, so that is a great tip.? Yes, using Python. ? From: [email protected] <[email protected]> On Behalf Of 闯ü谤驳别苍 Reinold via groups.io
Sent: Friday, 15 July 2022 1:02 PM To: [email protected] Subject: Re: [TWS API] updateAccountValue callbacks received but not accountDownloadEnd ? Details depend on your application architecture, your framework(s), and to some degree the programming language you use. In the simplest case you could use a model (as in Model-View-Controller) with read-only fields for the account values you are interested in. Callbacks from the initial request and from ongoing incremental updates simply change the corresponding fields in the model. The various client parts read the most recent value from the model when they need a value. In case you can use "Observable" data objects or some kind of "Data Binding" framework for fields in your model, updates from TWS API callbacks can trigger chains of notifications and method calls in your client. That can work in single-threaded and multi-threaded designs. I assume when you mention "thread event object" you refer to Python. I am not fluent enough in Python to give you concrete advice and "thread event objects" may very well all you need. But there are Python libraries and frameworks available that implement "observable patterns" or more general "data binding" services that may provide more features and more convenient APIs with less programming effort. 闯ü谤驳别苍 |