开云体育

Hi All,

Just responding to the questions about eSignal/IB. We'll have a

of IB integrated into eSignal sometime in August. It's hard to say

August 1 or August 31 as we're putting out lots of new features in

it's definitely coming in August.

Matt Gundersen @ eSignal

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better

--- In twsapi@y..., "Kent Rollins" <kentr@m...> wrote:

I thought there were 3 API's: DDE, ActiveX, and sockets. Were

3 just

recently thrown together? And were they all in the original TWS?

The ActiveX and sockets are one and the same. ActiveX is just a

with code to provide the sockets functionality into an ActiveX
environment. There is also a C++ wrapper for the sockets, so you

use thier Api without actually dealing with the sockets. The C++
wrapper api is documented.

The sockets api itself is 'not documented', but some of us figured

out by referencing the C++ wrapper code. The socket api works, has

few issues, and a few functions that just dont work.

The C++ wrapper for the sockets is just plain 'unuseable'. It has
indirection errors, and is not capable of being destructed, it

when you destruct it.

The whole setup is useable, it's just not ready for prime time, and
definitely not ready for folks that expect all the functionality
to 'just work'. It takes a significant effort to get the
understanding of what data is useable, and when, then it takes a

of special case code to accomodate it all, but, once you have it

figured out, it's useable for most applications, with a few
exceptions. I have one that we are probably going to shelve here
until some of the issues are resolved, because TWS just doesn't
behave well with the order volume it generates.

I would suggest, anybody seriously considering investing

in creating something to use this interface, take the time, read

entire list of postings here, thru the last few weeks, pretty much
all of the pitfalls have been posted here in one form or another,
with various means of getting around them. Building simple order
entry is pretty strait forward, but anything that actually does
active management of positions is quite likely to step in some/all

the pitfalls.

I thought there were 3 API's: DDE, ActiveX, and sockets. Were all

recently thrown together? And were they all in the original TWS?

I have built a sheet that I was pretty happy with in
Excel. I use ActiveX to
create all my orders etc. I have never had any
problem with it so far.
However I am considering moving to DDE for 2
reasons.

1, It seems that DDE has more functionality.
Specifically I want to be able
to modify and OCA order without cancelling an order
and reissuing botht the
stop and the target orders. I beleive that DDE has a
modify order ability
whereas activeX does not.

Please correct me if I am wrong.

2. IB support recommends DDE over ActiveX. Or has
done in the past.

So if I am correct that you can modify orders with
DDE can you answer these
questions.

1. Using the demo sheet adn the IB Demo software
what is the username I need
to put in so I can play at sending orders.

2. Active X is pretty simple stuff being event and
method driven but I am
not clear on how DDE works at all. It appears that
you place a value in a
cell that is a contiuous link to the IB software is
this correct?

3. A link that looks something like this
=server|topic!id?reqType?field2 ?

4. I know I am confusing two different approaches
but how is an order
actually sent. DO I just place a value in a cell
with reqtype=place
and it just happens?

Confused? I am.

Thanks for any help you can give me.

regards

Chasman

Probably just a feature creep cascade. "Hey, can you make it so we can
access data from TWS via DDE?" "Sure!" "Hey, can you make it so we can
place orders using the DDE interface?" "Sure!" "Hey, DDE sucks. Can you
give us an ActiveX interface for all this?" "Sure!" and on and on.

I completley second this suggestion. I am astounded at how

they have made this...perhaps complex is a better word.

Programming is intrinsically easy...the difficulty and complexity
seem to arise out of all the bandaids that need to be applied to
handle the what if's

I dont understand how the API would be difficult to program. IMHO
they need to enable direct server connections, for data, and as

accounts as one wants to attach to.

Then for the accounts it seems like a piece of cake to devise, and
build to a standard...

I am really at a loss as to how explain the present state of

Scott

--- In twsapi@y..., "Kent Rollins" <kentr@m...> wrote:

I maintain that the best solution would be to get TWS out of the

loop

completely. IB should create a socket interface on their servers

that we

can connect to from ours. Having TWS implement all these

interfaces is poor design and they obviously aren't staffed for

it. If they

are bringing in ONE more programmer to dedicate to the TWS API's,

we can

expect more difficulties in the short term.

Kent


----- Original Message -----
From: "grozzie2" <grozzie2@y...>
To: <twsapi@y...>
Sent: Thursday, July 25, 2002 3:18 AM
Subject: twsapi: Re: Event driven garbage

Let?s assume that the portfolio event once will have a bug: It

reports the

position 1 all the time.

If you want to be flat in that position, you application will

sell.

Than your application will think one minute later, that it has

sell

again, and so on.

So after an hour, your application sold 60 contracts, you are in

reality

short 60 and your application just wanted to have no position

the API is

still showing long 1 position.

I am aware of this type of consequence, and it's the 'tuff one' to
deal with, but, it has to be dealt with. Your comments on error
messages etc are valid, if you are working with the

user is within ear shot of the computer, and can come correct a
problem'. That's not always a valid assumption, and in our case,
it's a design specification (customer driven) that we assume no
operator at the computer, so, programs must 'handle every

So, we make philosophical decisions, and then place limits

how far it'll go'. Your situation described above, shows the

of 'assume the broker is right', but then look at the flip side.
Your program does 500 trades thru the day, and it's now sitting
between trades, and 'thinks' its flat. One of the trades from 4
hours ago is now broken, and suddenly the broker starts
reporting 'you are short', and the market is ramping to the

Since I have no way of simulating a broken trade, I have NO CLUE

tws will report that, and the documentation certainly doesn't

us

what messages will arrive at what callbacks to inform of a broken
trade. In this scenario, it's best to 'get flat', and then alert

the

correct people in whatever manner is prescribed. I guess tho,

says it all. In the event of a change in position 'out of the

blue',

it's a sad statement, when we have to sit here and ponder, geee,

this a broken trade, or just another idiosyncracy of TWS ?

There will ALWAYS be situations that come up, that a program just
cannot resolve. The key to these situations, is document what

happen, and make sure it's the 'least risk' method of handling
a 'totally bad situation'. Defining the 'desired action' is
definitely somewhat unique to each deployment. In the above
scenario, you prefer to get a notification, and deal with it
manually. My customer prefers to 'get flat, deal with it after

fact'. The scary part is, i'm actually starting to believe, in

event of a discrepancy, it's more likely to be a TWS error than

is

to be 'real'.

In it's current form, IB interface is unsuitable for unattended
operations. TWS just has to many 'issues' when it comes to the
concepts of real time and process control. This was actually a

disappointment when we started working with this stuff, because we
have implentations on other brokers that function fine in totally
unattended modes of operation. All implementations have failure
modes, but every other system i've worked with, the failure modes

are

identifiable, and software can make 'intelligent' choices for
handling failure modes. TWS doesn't even let a client application
know when it loses it's connection to IB, its just another one of

the

things a client applicaton has to 'guess' about.

In our shop, real time process control is the 'real business'. We
view trading as just another 'mission critical real time process'
that needs to be controlled. It's the nature of the beast, most
folks that want this kind of software, want it on windows, for a

of reasons. When I first looked at TWS, I thought I saw a

chance to take trading off windows, and deploy it on a robust

failure

tolerant environment. There's a few little things about TWS that

are

going to prevent that, but, it's not a big deal anymore, simply
because a system is only as strong as the weakest link. Moving

trading onto a redundant *nix based host wont make much

when all the failure modes occur from TWS itself :(






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



Your use of Yahoo! Groups is subject to

I maintain that the best solution would be to get TWS out of the

completely. IB should create a socket interface on their servers

can connect to from ours. Having TWS implement all these different
interfaces is poor design and they obviously aren't staffed for

are bringing in ONE more programmer to dedicate to the TWS API's,

expect more difficulties in the short term.

Kent


----- Original Message -----
From: "grozzie2" <grozzie2@y...>
To: <twsapi@y...>
Sent: Thursday, July 25, 2002 3:18 AM
Subject: twsapi: Re: Event driven garbage

Let?s assume that the portfolio event once will have a bug: It

reports the

position 1 all the time.

If you want to be flat in that position, you application will

Than your application will think one minute later, that it has to

sell

again, and so on.

So after an hour, your application sold 60 contracts, you are in

reality

short 60 and your application just wanted to have no position and

the API is

still showing long 1 position.

I am aware of this type of consequence, and it's the 'tuff one' to
deal with, but, it has to be dealt with. Your comments on error
messages etc are valid, if you are working with the assumption 'end
user is within ear shot of the computer, and can come correct a
problem'. That's not always a valid assumption, and in our case,
it's a design specification (customer driven) that we assume no
operator at the computer, so, programs must 'handle every scenario'.
So, we make philosophical decisions, and then place limits on 'just
how far it'll go'. Your situation described above, shows the limit
of 'assume the broker is right', but then look at the flip side.
Your program does 500 trades thru the day, and it's now sitting
between trades, and 'thinks' its flat. One of the trades from 4
hours ago is now broken, and suddenly the broker starts
reporting 'you are short', and the market is ramping to the upside.
Since I have no way of simulating a broken trade, I have NO CLUE how
tws will report that, and the documentation certainly doesn't tell

what messages will arrive at what callbacks to inform of a broken
trade. In this scenario, it's best to 'get flat', and then alert

correct people in whatever manner is prescribed. I guess tho, this
says it all. In the event of a change in position 'out of the

it's a sad statement, when we have to sit here and ponder, geee, is
this a broken trade, or just another idiosyncracy of TWS ?

There will ALWAYS be situations that come up, that a program just
cannot resolve. The key to these situations, is document what will
happen, and make sure it's the 'least risk' method of handling
a 'totally bad situation'. Defining the 'desired action' is
definitely somewhat unique to each deployment. In the above
scenario, you prefer to get a notification, and deal with it
manually. My customer prefers to 'get flat, deal with it after the
fact'. The scary part is, i'm actually starting to believe, in the
event of a discrepancy, it's more likely to be a TWS error than it

to be 'real'.

In it's current form, IB interface is unsuitable for unattended
operations. TWS just has to many 'issues' when it comes to the
concepts of real time and process control. This was actually a real
disappointment when we started working with this stuff, because we
have implentations on other brokers that function fine in totally
unattended modes of operation. All implementations have failure
modes, but every other system i've worked with, the failure modes

identifiable, and software can make 'intelligent' choices for
handling failure modes. TWS doesn't even let a client application
know when it loses it's connection to IB, its just another one of

things a client applicaton has to 'guess' about.

In our shop, real time process control is the 'real business'. We
view trading as just another 'mission critical real time process'
that needs to be controlled. It's the nature of the beast, most
folks that want this kind of software, want it on windows, for a lot
of reasons. When I first looked at TWS, I thought I saw a wonderful
chance to take trading off windows, and deploy it on a robust

tolerant environment. There's a few little things about TWS that

going to prevent that, but, it's not a big deal anymore, simply
because a system is only as strong as the weakest link. Moving the
trading onto a redundant *nix based host wont make much difference,
when all the failure modes occur from TWS itself :(






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



Your use of Yahoo! Groups is subject to

Let?s assume that the portfolio event once will have a bug: It

position 1 all the time.

If you want to be flat in that position, you application will sell.
Than your application will think one minute later, that it has to

again, and so on.

So after an hour, your application sold 60 contracts, you are in

short 60 and your application just wanted to have no position and

still showing long 1 position.