80 Members in less than 24 hours....

I had no idea.

I think this goes to show that there are many interested in IB's API,
and that the present sources of information exchange are lacking a
bit.

I hope this is succesful board. All members are encouraged to ask and
answer questions. Feel free to post source code examples to simple
problems for beginners in the files section

This board is completely unmoderated. Act responsiblely.

The race is on to produce killer app's and ats for IB API.

I wouldn't at all be surprised to see third party plugins popping up
like sand fleas within 6-9 months

This can only be good for the consumer. Competition is great.


Scott
Owner TWSAPI

IB management

Please view the following site.



I would like to get the all clear from you guys on this Yahoo message
board. The board merely expands on the API discussion on the present
IB board. Using the Yahoo forum we can exchange files, post
graphics, and search threads by keyword.

Please send this up to the proper management level.

I would yank the banner but I think it looks good, and you guys get
free advertising.

There are two links to the IB site.

One to the home page and a second to the users guide.

Scott
Owner TWS API Yahoo board

I am making a better order entry tool for IB intraday traders. Way
better considering my competition at this point...IB TWS

I am a loyal customer of IB and there exists no device to accomplish
what I want to do. Only a method. I am implamenting that method and
it will precipitate into the device I seek.

In the process I will produce a piece of software that now does not
exist free or commercially. I have several friends who use IB for
trading ES and NQ. They wait with great anticipation of this
software...

It is that simple.

As to retrieving market data, I am pulling it in from Qcharts via
Active X...

I don't use that data other than for a x-ref in a display at this
point. I am a discretionary trader.

As a bonus, I enjoy programing and the challenges and opportunity it
affords.

When I am done and I have beta'd the software with a few other guinea
pigs, and someone wants to pay me for my effort...that would be
iceing on the cake....

Scott


--- In twsapi@y..., "Marcus Jellinghaus" <Marcus_Jellinghaus@G...>
wrote:

I would like to know what you are using the API for. Why did you

decide to

make something on your own instead of using some existing solution?

What

should be the pro?s of your solution versus the exiting solutions?

-Are you retrieving the market data? (As you could do it with

eSignal, for

example)

-Are you retrieving the market data and make some rather complex
calculations with it?
(as you could probably do it with tradestation or wealth-lab)

-Are you developing a different or better order entry tool?
Did you look into other order entry tools, like Jerry Medved?s
Quotetracker, CyberX2, Cybertrader Pro, Datek?s Tools, Realtick, ..?

-Are you developing an automated trading solution?
I couldn?t find an existing stock trading solution for several

stocks.

Marcus




-----Ursprungliche Nachricht-----
Von: marinindextrader [mailto:marinindextrader@y...]
Gesendet: Sunday, June 09, 2002 5:34 AM
An: twsapi@y...
Betreff: [twsapi] XLS DDE, C++, Delphi: Can Someone Post A Sample

Project

Please?


Build it and they will come....

We need someone who is fluent in the use of TWS-OCX to build a

single

sheet project in the above languages

It need do nothing more than log in, and retrieve a single user
symbols data set and print the price to a cell or label.

There are many many people who are begging for demonstration

projects

like this.

I posted one in VB in the files section of this board. We need the
other languages done....

We need one for XLS-VBA DDE, C++ OCX, and Delphi too.

When the inevitable clamour begins, we can simply point them at

these

files as a resource...

Consider it a contribution to humanity..

I will be posting a second VB project that uses MSHFlexGrid and
demonstrates in cell editing, and the display of the full data

set in

a row...

Scott




Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
twsapi-unsubscribe@y...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of

Service.

开云体育

Build it and they will come....

We need someone who is fluent in the use of TWS-OCX to build a single
sheet project in the above languages

It need do nothing more than log in, and retrieve a single user
symbols data set and print the price to a cell or label.

There are many many people who are begging for demonstration projects
like this.

I posted one in VB in the files section of this board. We need the
other languages done....

We need one for XLS-VBA DDE, C++ OCX, and Delphi too.

When the inevitable clamour begins, we can simply point them at these
files as a resource...

Consider it a contribution to humanity..

I will be posting a second VB project that uses MSHFlexGrid and
demonstrates in cell editing, and the display of the full data set in
a row...

Scott

I dont code in C++ (yet) but do have an IDE in my Enterprise suite.

I loaded up a new project with a new Main, and went to Project/Add To
Project/Components and Controls. From there the Compenents and
Controls Gallery pops up.

Selecting Registered ActiveX Controls I found the Normal TWS OCX
Class.

I inserted it in to a blank OCX project and all properties, methods
and objects were present...

Doesnt look like a problem at all...


If you have a C++ IDE...fire it up and check it out.

Scott




--- In twsapi@y..., Richard Foulk <richard@s...> wrote:

So what's the trick to getting the IB test mess to build with C++

6.0?

Thanks

Richard

So what's the trick to getting the IB test mess to build with C++ 6.0?


Thanks

Richard

Author Message


TriPack
Unregistered guest
Posted on Friday, June 07, 2002 - 11:16 am:

----------------------------------------------------------------------
----------
I agree alanm, and am glad you spoke out in favor of the transaction
history. I would like to see it too. It personally makes more sense
to me to provide a actual fills prices rather than an average price
history. It takes the rounding problems out of mix.


alanm
Unregistered guest
Posted on Thursday, June 06, 2002 - 11:40 pm:

----------------------------------------------------------------------
----------
Why not report the actual fill prices instead, since these will be
exactly correct, instead of having to extrapolate it from the
average?


TriPack
Unregistered guest
Posted on Thursday, June 06, 2002 - 10:45 am:

----------------------------------------------------------------------
----------
It appears that this request takes the form of a request for a bug
fix. We need the precision improved for the average prices reported
via the orderstatus event (and other events that report average fill
prices). Regardless of whether a full transaction history is
provided, the average price precision needs to be improved from two
rounded decimal places so that we can calculate fill prices
accurately.


Bart Gelens
Unregistered guest
Posted on Wednesday, June 05, 2002 - 12:56 pm:

----------------------------------------------------------------------
----------
Problem: Twice a "filled order" confirmation with different average
prices?

I am using the TWS stand alone version (build 765) (ActiveX API).
Sometimes, when I place an order like Id=10382 NQM2 BUY 1 4818.50
LIMIT
I get 2 OrderStatus events:

OnOrderStatus: Id=10382 Status=Filled Filled=1 Remain=0 price=4818.50

OnOrderStatus: Id=10382 Status=Filled Filled=1 Remain=0 price=9635.00

The first (average) price is exactly the same as the requested price.

The second price is multiplied by (almost) 2!


This only happens while using the official account. If I log in as
cdemo user, it seems to be working fine. Did anyone have a similar
experience?

Regards,

Bart.


TriPack
Unregistered guest
Posted on Wednesday, June 05, 2002 - 10:41 am:

----------------------------------------------------------------------
----------
"The API is always reporting the average price. "

Marcus, thanks for the clarification in your post. Well that is good
to know. I can make up a formula to account for the averages. My
original impression was that only the last fill reported was an
average. I should be able to solve for rounding (at least in my case
with the EMINIs) because they have a set .25 or .5 tick price for ES
and NQ. Stocks will be more difficult because of the one cent and sub-
one cent prices (in some cases).

Yes, giving us an unrounded average would make it easier. Giving us
full transaction history would also do the trick.


Marcus Jellinghaus
Unregistered guest
Posted on Wednesday, June 05, 2002 - 09:58 am:

----------------------------------------------------------------------
----------
The API is always reporting the average price. The advantage of that
is, that we do not have to calculate the average price, the
disadvantage is, that we have to calculate the part fills. Of course,
the API could return the values the other way round or both.

I think since we program anyway, the calculation of the part filles
shouldn?t be a big problem.

From my calculations, the price of the second part fill should be
((20*1043.44)-(15*1043.5))/5 = 10.26.

You are right with the rounding errors. But the API users can
calculate exactly, the problem is that the API gives rounded numbers
which leads to wrong prices:
Yesterday I bought 600 stocks in 3 part-fills:
100 x 5.9200 Average Price: 5.92
286 x 5.9160 Average Price: 5.917036
214 x 5.9200 Average Price: 5.918141

I have the first 2 numbers from the account statement and calculated
from that the average price. The API always returned 5.92 as average
price, which is rounded. If the API would give the correct number, we
could calculate correct partfills.
So the partfill prices may be wrong in the area smaller a cent.


The fill prices are also sometimes different because IB rounds the
turnover to full cents and so charges other prices than the tick was
at the exchange. But I guess the reason is that most exchanges also
round the turnover to full cents.


TriPack
Unregistered guest
Posted on Tuesday, June 04, 2002 - 03:40 pm:

----------------------------------------------------------------------
----------
Let me use an acutal example from my debug window. I place a limit
order to sell 20 ES @ 1043.25 Limit and the following is my initial
feedback.

Tws1_orderStatus 224 PendingSubmit 15 5 1043.5
Tws1_orderStatus 224 Submitted 15 5 1043.5
Tws1_orderStatus 224 Filled 20 0 1043.44

So from this I *infer* (are fills reported on "PendingSubmit"
and "Submit" events reliable?) that the first lot of 15 was filled at
1043.5 but we have to deduce that the 2nd lot of 5 was filled at
1043.25. Is it just me or is it strange that we have to either
mathematically figure or use some other method to get the last fill
price when you have a partial fill? In this case you can infer that
it was filled at 1043.25 on the last 5 cars because of the limit
price. In other cases it isn't so clear cut. When mathematically
figuring, we have to deal with the rounding errors.

I request executions, and after a delay of about 20 seconds I get the
following information:

Tws1_openOrder1 225 ES FUT 200206 0 ? GLOBEX USD
Tws1_openOrder2 225 SELL 15 LMT 1043.25 0 DAY F92 O 2
Tws1_orderStatus 225 Filled 15 0 1043.5
Tws1_openOrder1 226 ES FUT 200206 0 ? GLOBEX USD
Tws1_openOrder2 226 SELL 5 LMT 1043.25 0 DAY F92 O 2
Tws1_orderStatus 226 Filled 5 0 1043.44

Why isn't the price on the 5 contract fill reported as 1043.25
instead of reporting the average price for the whole lot? This seems
like a bug to me. If it was intentionally programmed this way then
perhaps it needs to be rethought because it makes it unnecessarily
difficult to compare the fills listed in the TWS vs the ones reported
via the TWS API. Also, why does it take so long for the execution
report to come out? I'm not really asking for new features, just
wondering why the current reporting mechanism makes no sense. Why
don't they just give us our transaction history? It seems to me that
people who are using this successfully now must have done something
to compensate for the fact that the API is giving average price
instead of just reporting each fill.


Marcus Jellinghaus
Unregistered guest
Posted on Tuesday, June 04, 2002 - 01:54 pm:

----------------------------------------------------------------------
----------
I do not really get your point. To take your example, I first get an
orderstatus event where 30 are filled and 70 are remaining. So it is
easy to see that it is just part fill. I also know the filled price.
After that I get a second orderstatus event which says 100 filled, 0
remaining. So I know that the order is filled, I know average price,
from that and the first part fill I know the data of the second part
fill etc.

I would prefer it if IB would solve the existing problems with the
API rather than adding new functionality, which is not really
necessary.

Best regards,

Marcus


TriPack
Unregistered guest
Posted on Tuesday, June 04, 2002 - 11:15 am:

----------------------------------------------------------------------
----------
I like the TWS API a lot. It works well for all but partial fills,
which become a pain to manage. It would be nice to push a PartialFill
status update through the "orderstatus" event. I'm using the TWS Ax
OCX.

Probably the best way to implement this would be to have the
PartialFill status in the orderstatus event fire off whenever there
is either a partial or full fill. For example if you put in an order
for 100 shares and are filled on 30 then 70, you would receive two
orderstatus events with the PartialFill for 30 filled with 70
remaining and then 70 filled with 0 remaining. This would leave the
Filled status unchanged - it would continue to just report when the
full position has filled. If you put in an order for 100 shares and
it was filled all at once, you would receive both the PartialFill
event for 100 shares filled 0 outstanding and the same event for
Filled shares (so as not to mess up legacy systems that other
programmers have implemented).

This VB Project Can Be DownLoaded Here:



--- In twsapi@y..., "marinindextrader" <marinindextrader@y...> wrote:

Sample Code on Basic connection and display

Option Explicit
' contract description vars

Dim id As Long
Dim symbol As String
Dim secType As String
Dim expiry As String
Dim strike As Long
Dim right As String
Dim exchange As String
Dim curency As String
Dim port As Long


Private Sub Command1_Click()
Tws1.reqMktData id, symbol, secType, expiry, strike, right,

exchange,

curency
End Sub

Private Sub Command2_Click()
Tws1.cancelMktData id
Label1.Caption = "cancelMktData"
End Sub

Private Sub Form_Load()

'Here I have set all of the values as static constants for
demonstration purposes

port = 7496 'this is the port number you wrote down
id = 1 '
symbol = "ES"
secType = "FUT"
expiry = "200206"
strike = 0
right = ""
exchange = "GLOBEX"
curency = ""
Tws1.Connect "", port 'This must be the very first thing that is
called


End Sub
'now have it display the price of the security
Private Sub Tws1_tickPrice(ByVal id As Long, ByVal tickType As

Long,

ByVal price As Single)

If id = 1 Then 'reference the reqMktData call by its id number
If tickType = 4 Then 'tickType 4 is Last Price
Label1.Caption = Format(price, "0.00")
End If
End If


End Sub

Sample Code on Basic connection and display

Option Explicit
' contract description vars

Dim id As Long
Dim symbol As String
Dim secType As String
Dim expiry As String
Dim strike As Long
Dim right As String
Dim exchange As String
Dim curency As String
Dim port As Long


Private Sub Command1_Click()
Tws1.reqMktData id, symbol, secType, expiry, strike, right, exchange,
curency
End Sub

Private Sub Command2_Click()
Tws1.cancelMktData id
Label1.Caption = "cancelMktData"
End Sub

Private Sub Form_Load()

'Here I have set all of the values as static constants for
demonstration purposes

port = 7496 'this is the port number you wrote down
id = 1 '
symbol = "ES"
secType = "FUT"
expiry = "200206"
strike = 0
right = ""
exchange = "GLOBEX"
curency = ""
Tws1.Connect "", port 'This must be the very first thing that is
called


End Sub
'now have it display the price of the security
Private Sub Tws1_tickPrice(ByVal id As Long, ByVal tickType As Long,
ByVal price As Single)

If id = 1 Then 'reference the reqMktData call by its id number
If tickType = 4 Then 'tickType 4 is Last Price
Label1.Caption = Format(price, "0.00")
End If
End If


End Sub

Test Post