Even after you cancel a request there may be messages wandering around the Internet that may appear many seconds later.

You need to accept any message at any time. If you receive tick data you're no longer interested in then you need to ignore.it.

开云体育

On Tue, Jul 26, 2022 at 06:09 PM, David Armour wrote:

after the display and buffer are cleared.

...this means that this is also after all the market data subscriptions have been cancelled.

I have a C++ GUI application which on which at a user request, the list of symbols will be cleared and all the market data requests will be cancelled, and ultimately the buffer holding the records for the GUI display is cleared.

The issue I have is that every now and again I get a crash because there are still incoming tick messages (price, volume, etc.) in the queue after the display and buffer are cleared.

Is there any way I can test the incoming message queue to see if there are any messages to process? Is there a way to clear that queue to prevent further GUI update calls from the reader thread?

Here's the screenshot of what I just downloaded today.
I realized the problem goes away if I don't change to an xlsx file and leave it in xls - then its like all the lines are populated at once instead of waiting for a few seconds each line like this.

Hi all, new to this forum and ActiveX API here.
Started using the standard sample TwsActiveX.xls and trying to get it download my account info.
But after downloading about 5/10/40 rows it stops downloading anymore rows.? (This seemed to work on Wed, but yesterday and today it's not working).
Am I missing something on my configurations??

Brendan is correct about the UNSET_DOUBLE or Double.MAX_VALUE the various languages use to indicate "undefined value". The same is true for integer fields where the Integer.MAX_VALUE (2^31)-1 = 2,147,483,647 is used as the UNSET_INTEGER indicator.

You should get "undefined realizedPNL" only for commission reports of entry trades, since there is no PNL from price changes yet. Commission reports for exit trades will show the actual realized PNL for that trade.

Depending on how you think about PNL, you could set "realizedPNL = -commission" for entry positions (when realizedPNL is undefined) since the commission you pay for entering into the position is a small loss right from the start.

闯ü谤驳别苍

Hi all - new to this forum, hoping to learn a lot here!?

Wondering if anyone has been able to use the excel API to pull in Beta to the S&P500 for a particular stock that is in your portfolio? I am looking to calculate a beta-adjusted equity exposure figure for each position.

Thanks,
Justin

When I execute an order I get the?commissionReport.But I cannot read the?commissionReport.realizedPNL such like?1.7976931348623157e+308.
When I create a new position, the?commissionReport.realizedPNL shows?1.7976931348623157e+308.After the position closed,the?commissionReport.realizedPNL shows the normal profit and loss amount.
I'd like to export the Profit and loss to csv after every positions closed.But I don't know how to handle the??commissionReport.realizedPNL such like?1.7976931348623157e+308.
It cannot export?commissionReport.realizedPNL to csv by?writer.writerow(commissionReport.realizedPNL).It shows error message:csv.Error: iterable expected, not float

I don't know how to do? Any ideas is welcome.


--


------
Forex trader
David Liao

Richard already pointed the relevant time-in-force options out and you can learn more about GTC orders in . Interesting read, since there are a few (not so obvious) events that can cancel your order.

Your question made me curious about the autoCancelDate field you mentioned. I had seen it before but never paid attention to it so I did a little research.

The order object field autoCancelDate, and one called autoCancelParent must have been around for quite a while, but at least since APII 976.1. Documentation is very thin but the reference guide says:

• - Specifies the date to auto cancel the order.
• - Cancels the parent order if child order was cancelled.

And the for 10.10 say "Added AutoCancelParent attribute to placeOrder/openOrder". I read that as "the order object field autoCancelParent is now sent to and received from TWS/IBGW".

autoCancelDate is not mentioned in the release notes so I checked the API source code. At least in the Java API, values for autoCancelDate are ignored when order objects are sent to TWS/IBGW via placeOrder. In other words the field can not be used to cause order cancellation at a certain point in the future.

But the field is properly initialized in order objects received from TWS/IBGW via openOrder callbacks. So the field could possibly carry the date/time when an order was cancelled related to autoCancelParent = true. But that is just a guess.

闯ü谤驳别苍

开云体育

Hi All,?

I was going through TWS API order structure. I found that we have GTC orders in which we can specify date and time to cancel the order. Why we have seperate field called autoCancelDate? Isn't it same as GTC.

Thanks
Ajinkya

I had a couple minutes and a paper account with no positions and was able to replicate the TWS behavior you report:

• A (paper) account has no positions (other than cash)
• The portfolio/account technically has unrealized and realized P&L of 0 but the (real-time data based) TWS portfolio window shows no Daily P&L values or positions at all.

In this case, subscriptions to trigger a single callback only for the first client that connects to TWS, and dailyPnL,, unrealizedPnL,, and realizedPnL? are reported as 0. That client does not receive any further callbacks (there are no positions) and all subsequent clients of that TWS do not event receive the initial callback.

That behavior is definitely inconsistent, but your client should not have to lock up. In fact, for my taste, I would not have expected a callback for the first client to take place:

• Subscriptions to receive no callbacks unless the portfolio actually has a position entry for that instrument.
• and are real-time market data based P&L calculations and really make only sense if the portfolio actually has positions
• The TWS Portfolio window shows no entries or values in that case

You may want to take a look at your client architecture and consider a "PortfoilioModel" or "AccountModel" implementation similar to those used in Model-View-Controller architectures. Callbacks from TWS API subscriptions update values in the model when they happen and your client reads the most recent values from the model when it needs one. During startup, all model values are either initialized with 0 (or "undefined" if that is what you prefer) and your client operates properly with and without the callback.

The TWS API is asynchronous and event oriented in nature and your client must be resilient and always be prepared that an event just does happen (for many reasons).

A couple other quick observations:

• TWS does maintain a proper subscription to reqPnL (and reqPnLSingle for non-existing positions) even if the initial zero value callback does not occur.
• As soon as on order is placed and a position exists, real-time P&L callback arrive immediately
• And finally, subscriptions to does trigger zero value updates for account values "RealizedPnL" and "UnrealizedPnL" during startup for all clients, even those that do not get the reqPnL callback.

You could file a trouble ticket with IBKR for this, but I think it would get a very low priority or may even be rejected by engineering right away.

Hope this helps,

闯ü谤驳别苍

I ran two and more clients connected to the same IB Gateway 981.3o in paper and real accounts and received no error conditions. Everything worked fine, as expected, and just like always, and I cannot confirm any changes in the policy for sharing of market data by multiple clients connected to the same IB GW/TWS.

My clients subscribed to a wide range of instruments (40 to 80 each), including TickByTick and Level II data feeds.

Maybe you could enable API logging in your IB Gateway and share the occurrence of 10197 errors in your setup?

闯ü谤驳别苍

On Sat, Jul 16, 2022 at 10:42 AM, <liulinglll@...> wrote:

ibgateway is 981 and only the 2nd connected client has 10197...it happens consistently

based on previous discussion about 10197 IB definitely changed rules...