Glad to....Let the listing and ranking begin.

Scott

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

Richard, on one hand I agree with you.
One the other hand, there a lot?s of frustrating things:

When I became and IB customer, they (the swiss IB guys) told me

that the API

was finished and not beta. I was the one who told them later, that

it was

wrong after Ernie (TAC) told me that it is beta.
I found lots of bugs. I reported them to IB. I never got a reply.

The only

positive result was, that they fixed some of the bugs.
I even found bugs which occured randomly and caused wrong

executions:

-Once I placed an order through the API. TWS showed the order

correctly. The

order was a limit order and should have been executed. There was

more than

30 minutes, where the order could have been filled. But IB didn?t

fill the

order.
An other time they filled too much: I placed an order for 1000

stocks and

they filled 1500 stocks.
An other time, they filled the order correctly but TWS showed still

an open

order, which I coulnd?t cancel.
Every time they agreed with me that something went wrong on their

side. They

told me that they would fix it. But since they don?t have a detailed
enhancement report or version list or something, I never now what

they have

fixed and so I think that one should assume IB to be to unreliable

for

complete automated trading. But it is possible to do automated

trading if

you do lot of cross checks in your software which then send alerts

to you.

When I started with the API, I took the ActiveX-API and linked it to
Microsoft Access. Then I found several bugs, which I reported. One

bug-fix

was, that they no longer support the ActiveX for Excel. This is

quite

annoying or me, since I spent a lot of time on connecting MS-Access

and

ActiveX.
So I have to use an old version of the API, but this may lead to an
errorneous TWS.
So I have to switch to DDE. I asked several times, if they will

incooperate

the functionalities that ActiveX had. I never got a reply. So I

were not

sure for a long time, if I just invested my time in the wrong

brokerage

company.
BTW: I?m working for more than a year with Cybertrader, there API

team is

very responsive, and they told me from the first second that it?s

beta.

I worked 2 years for a mayor consulting company on a software

developement

project. We had a very successful project with one of germany?s

biggest

companies.
I think the reason why the project was so sucessful was

communication:

We had many beta testers and we spent most of our time on talking

to them.

So we knew exactly where they saw problems, what we should change

and what

they wanted.
The beta testers were very happy, because they knew exactly what we

are

going to do and that they have real impact.
The big anonymous group of future users of our software was also

happy

(that?s what we heared), because every body knew one of the beta

testers. So

everybody had the chance to understand the way we were developing

by talking

to one of the beta testers.
I don?t think that we developed our software a very special way, I

just

think this is how software should be developed. I talked to IB if

they

wanted to improve their API communication, but they didn?t want to.

I guess this group with more than 400 (?) members should be

important to IB.

If this would be the case, I would recommend that a moderator

(Scott, for

example) of IB sends once a week a email to IB with the most

important

questions and suggestions. IB answers the email and sticks to that,

what

they said. So IB would just have to answer one email per week

(shouldn?t be

too much work) and there would be some communication process.
I?m sure that somebody of the group would be interested in doing

that. But

I?m not sure if IB really thinks that 400 clients are important.

Marcus
-----Ursprungliche Nachricht-----
Von: Richard Foulk [mailto:richard@s...]
Gesendet: Monday, July 15, 2002 4:21 AM
An: twsapi@y...
Betreff: twsapi: let's do it right


Aloha,

I don't work for IB, I'm just a mostly satisfied customer.

This is just a reminder, that the TWS API is still very new and
in beta. That means bugs are to be expected.

The current code may be messy and unfinished, even terrible ...

Duh! It's beta!

Beta means the authors are still working on it. They're hoping
that beta testers (that's you) will let them know about problems
and bugs and design flaws so that they can fix them.

This is the best time to get things fixed. If you sit back and
say nothing then the opportunity will be lost.

The beta will eventually become a release and the best time to

offer

feedback will be gone. As long as there are sufficient problem

reports

flowing in the beta status should continue. But beta is a one-

time

thing, once it's gone -- it's gone!

Please, please, please report bugs to IB! Don't just work around

them.

That would be really dumb.


Thanks

Richard

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.

Richard wrote:

The current code may be messy and unfinished, even terrible ...

Duh! It's beta!

Beta code might be allowed to be messy and unfinished. It's NOT allowed to be terrible. Terrible code is just plain incompetent. If people are clueless enough to create terrible code then beta testing won't help. This is called "development by trial and error".

I'll know in a couple of weeks if the socket api is simply unfinished or it's hopeless. I'll send them my feedback in either case but I've been in the industry long enough (probably longer than the api developer has been ALIVE) to know a legitimate beta process from a company that's just winging it.

Is there a prioritized list of bugs? Is there a priority list of enhancements? Is there a schedule with a time frame for beta report gathering, tasks assigned to resources and release dates? I don't see any of this right now. I don't see a way to register as a beta user- they don't even know who the beta testers are!

Don't get me wrong. I do appreciate IB putting effort into creating the api's. I'm just questioning whether this is a legitimate effort or just a marketing checklist item.

- Nick

开云体育

Aloha,

I don't work for IB, I'm just a mostly satisfied customer.

This is just a reminder, that the TWS API is still very new and
in beta. That means bugs are to be expected.

The current code may be messy and unfinished, even terrible ...

Duh! It's beta!

Beta means the authors are still working on it. They're hoping
that beta testers (that's you) will let them know about problems
and bugs and design flaws so that they can fix them.

This is the best time to get things fixed. If you sit back and
say nothing then the opportunity will be lost.

The beta will eventually become a release and the best time to offer
feedback will be gone. As long as there are sufficient problem reports
flowing in the beta status should continue. But beta is a one-time
thing, once it's gone -- it's gone!

Please, please, please report bugs to IB! Don't just work around them.
That would be really dumb.


Thanks

Richard

price and size events DO NOT fire concurrently...if you attempt to
craft a TOS display or a technical from the data, it will be
eroneous.

There are threads on the board that point out what is wrong with the
data stream...

Read this before you decide to proceed:



Scott
Waste of time IMHO



--- In twsapi@y..., "aussiedavid2002" <dgrubnic@h...> wrote:

Just started working with IB's Excel DDE file. So far I've got it
working in excel using their twsdde.xls file. My question is, can I
create a sheet for each symbol and have the time and sale data go
into ascending rows as it's updated. Currently I have 1 row per
Symbol that is updated. If I can get this date to update per row,

is

it then possible to run real time indicators ( moving avg, macd,

cci)

and possibly trigger alerts. Also how difficult would this be to

do,

as my macro experience is limited.

Thanks a bunch in advance for all responses…

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

In the "PlacingOrders" example in the Files section of this Group,

a

variable is created called "NewID" whenever an order is placed.

Lets say I've placed an order and now want to cancel or modify this
order.

Do I get the order in questions' ID from
the "orderstatus", "openorder1", or "openorder2" events?

Cancel using the same id number you used to create it.

In the "PlacingOrders" example in the Files section of this Group, a
variable is created called "NewID" whenever an order is placed.

Lets say I've placed an order and now want to cancel or modify this
order.

Do I get the order in questions' ID from
the "orderstatus", "openorder1", or "openorder2" events?

If I want to send a cancel order I don't think I can use the "newid"
variable because this will create a new incremanted ID?
---------------
Private Sub cancelbtn_Click()
Tws1.CancelOrder newID
End Sub
----------------

Thanks for the help.

Just started working with IB's Excel DDE file. So far I've got it
working in excel using their twsdde.xls file. My question is, can I
create a sheet for each symbol and have the time and sale data go
into ascending rows as it's updated. Currently I have 1 row per
Symbol that is updated. If I can get this date to update per row, is
it then possible to run real time indicators ( moving avg, macd, cci)
and possibly trigger alerts. Also how difficult would this be to do,
as my macro experience is limited.

Thanks a bunch in advance for all responses…

开云体育

Your are making the assumption here that they are on the same

local

host. Our target end environment has analysis and trading on
separate computers, in separate locations.

I thought only the local host "127.0.0.1" is supported for now, from
IB's source code. Is this not the case any more?

-weidong

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

What is a Wrapper?

The actual api is defined as a series of data strings to pass thru
the TCP socket. The wrapper is a bunch of code with various entry
points that provide functions such as 'place order' etc.

A call to placeOrder with parameters, sets up the parameters to a
series of function calls implemented by the wrapper code, which
results in socket i/o calls (the actual connection to TWS).

When i started this project, I assumed the wrappers provided by IB
(in the library file .lib) would be 'solid and tested'. I was wrong,
I took a good look at the source for the first time today. The
libraries do no error handling, are not thread safe, and have some
very strange pointer code that kinda hints somebody was playing with
pointers 'till it worked'.

When I first started looking at the code for the .lib, I was
concerned it was going to be horribly complex, and a nightmare to
figure out, and impossible to fix. I was wrong. It's very simple,
impossible to understand why they used all the MFC stuff, and gonna
be trivial to fix in comparison to the 'big picture' of the rest of
our code here.

I have to step out for an hour or so, when I get back, gonna dive
into re-writing the ESocketClient. It wont be a huge task to get it
going today, provided TWS demo co-operates and stays online. In the
interest of keeping it compatible, I'll keep the exact same set of
input functions, but I'll encapsulate it better, with a worker thread
internally to do the reading of the socket messages. One of the
things that's bothered me from the start, requesting open orders only
seems to work when you first start up, doesn't after that. With a
quick re-write of this, I can include an implied disconnect and
reconnect on the socket at that point, so that requesting open orders
at any time will 'just work'.

I'll keep you guys posted, but after an hour of looking at it, the
problems I'm dealing with became obvious, it's not re-entrant, and
it's not thread safe. The messages are fairly strait forward, and if
dropping and reconnecting the socket on the fly works, then it's
possible to handle virtually any error condition, so, that's the
project later this afternoon, a re-write of that class to include a
worker thread, and some functionality to make it robust.

Will be interesting to see if there's any serious gotchas i didn't
see on the first go around.....

What is a Wrapper?

Also, as an experiment in response to your question I did the

following:

1) Connect to TWS
2) Request some data (account info)
3) Deliberately not read the entire reply
4) Close the socket
5) Open a new socket
6) The newly opened socket appears to work fine

Of course, it's still early in my experiments and things could

change, but

for now it seems that it's not fatal for the app.

Thank you VERY much. I did a quick recompile of the
c++ wrappers (found the code, didn't even realize it
was there), and have same problems as I did before,
but, it's pretty obvious why looking at the code.
There's a lot of exception handlers in there that
do nothing, absolutely nothing, and the connect/
disconnect code blindly closes sockets that were
never opened etc.

If the socket itself can be closed, and one can start
fresh with a new one, then I know, it's not so bad,
only the wrapper is causing the problems, and that I
can work around.

I think your question points more to API (SubClassing and Hooking)
calls to the system and which OS is better for that.

You would have to ask a more experienced programmer if one OS is
favored over the other. I would imagine it depends on the end use
destination of the software as well.

Generally speaking though I would go with 2000. Not because XP has
been problamatical. But because 2000 for me just humms right along.
Its multiple monitor support is darn near flawless...and that makes
me very happy.

Sorry if I cant be of more help.

Scott



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

Scott

thanks for your quick reply. If I may explore a little further, my
question is specifically related to XP vs. Win2000 as it relates to
EXCEL/TWS API DDE connection. Do you have a preference when it

comes

to this particular requirement?

-fm



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

wrote:

I use 2000 on my network, and so far, of all the Windows OS's, I

like

it best. Keeps on ticking, networking is a snap.

I think XP is pretty consumer oriented. I have it on my laptop

and

don't like the obfuscation of control elements. Its is as if MS

wants

to make XP difficult to tinker with. Then again I havnt played

all

that much with it, and it seems to work.

Scott

-fm

Scott

thanks for your quick reply. If I may explore a little further, my
question is specifically related to XP vs. Win2000 as it relates to
EXCEL/TWS API DDE connection. Do you have a preference when it comes
to this particular requirement?

-fm



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

I use 2000 on my network, and so far, of all the Windows OS's, I

like

it best. Keeps on ticking, networking is a snap.

I think XP is pretty consumer oriented. I have it on my laptop and
don't like the obfuscation of control elements. Its is as if MS

wants

to make XP difficult to tinker with. Then again I havnt played all
that much with it, and it seems to work.

Scott

-fm

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

"I think i broke the ice, and the c/c++ folks are speaking up now :)

It looks to me like there's 2 main focus groups looking at the TWS
api. The first, is what i would term the 'hobby folks', toying with
automated trading for the first time, and learning VB in the
process. The second group, developers that have been doing trading
type stuff for a long time already, and the interface to IB is 'just
another tool to go in the toolbox'."

BREAK

I think that we all could benefit from professional C++ programmers
using this forum for discussion. I would hate to see a splinter,
rather I would like to see heightened level of discussion. I just
started my programming about 4 months ago. Eventually I will move to
C++. For now, I stay with VB because I have not reached the
limitations of this Psuedo OOL...when I do I would be greatful for
any past discussions here concerning C++. Let it Rip.

In fact you may hasten that moment of transformation as you make all
of us aware of the power of a true OOL...

Please feel free to take the discussion in the direction you please.

Scott

I thought the TCP socket will take care of the reliability part
between TWS and your client. Besides they are on the same local
host, so the only chance is buffer overflow, and that should be
taken care of by the TCP protocal.

Your are making the assumption here that they are on the same local
host. Our target end environment has analysis and trading on
separate computers, in separate locations.

Now regarding the internect connection with IB, do you actually
experienced such disconnection causing the client blocked in the
middle of a message? Would be very interested to learn the

patterns

of "always where" it is blocked.

It's not so much as 'in the middle of a message', as 'is the
connection to IB still alive'. We currently process thru other
brokers, via different mechanisms, but, want IB in the loop. The
order volume generated by our setup can be significant, many
hundreds, and sometimes over a thousand, orders in a day. If the
system has 25 orders open in the market, and connectivity to the
broker dies, we need to know, so that manual procedures can be
initiated. Since the actual trading computer is sitting in a

cubicle

on another site, where there is redundant net connection, redundant
power, etc, we need to do all of this programatically, there is no
human interaction at the computer actually executing trades in the
market.

Anyway, I am very interested in your investigations. And if

enough

of us C++ users find this group too irrelevent to our project,

then

we should form our own group.

I think i broke the ice, and the c/c++ folks are speaking up now :)

It looks to me like there's 2 main focus groups looking at the TWS
api. The first, is what i would term the 'hobby folks', toying

with

automated trading for the first time, and learning VB in the
process. The second group, developers that have been doing trading
type stuff for a long time already, and the interface to IB

is 'just

another tool to go in the toolbox'.

IB is an intriguing tool too. It will be interesting to see where

it

all ends up.

I use 2000 on my network, and so far, of all the Windows OS's, I like
it best. Keeps on ticking, networking is a snap.

I think XP is pretty consumer oriented. I have it on my laptop and
don't like the obfuscation of control elements. Its is as if MS wants
to make XP difficult to tinker with. Then again I havnt played all
that much with it, and it seems to work.

Scott


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

I've managed to get the EXCEL/DDE/TWS API to work under Windows NT
4.0. I've been thinking about upgrading my system and my OS

choices

are Windows XP or Windows 2000. Is there a preference for either

OS

as far as the EXCEL/DDE/TWS API is concerned?

thanks
-fm

I've managed to get the EXCEL/DDE/TWS API to work under Windows NT
4.0. I've been thinking about upgrading my system and my OS choices
are Windows XP or Windows 2000. Is there a preference for either OS
as far as the EXCEL/DDE/TWS API is concerned?

thanks
-fm

Now here is the real question, and if you have the answer, it'll save
a lot of digging and trial/error on my part.

Is the error truely fatal, ie application must totally close? Or,
will TWS 'be happy' if you close the connection cleanly, and then try
restart.

Up until now, I've only used the wrapper libraries they provided, and
have got all the rest of our application 'happy' now. It's the
connect/disconnect problem that is my current show stopper, and if
simply fixing the wrappers will cure it, that shouldn't be hard.

My answer right now is that closing the socket and opening a new one will work. I guess I should have said that the error is fatal *for the current connection*.

I have aborted many times while snooping the protocol and I was able to simply run another test without restarting TWS.

Also, as an experiment in response to your question I did the following:
1) Connect to TWS
2) Request some data (account info)
3) Deliberately not read the entire reply
4) Close the socket
5) Open a new socket
6) The newly opened socket appears to work fine

Of course, it's still early in my experiments and things could change, but for now it seems that it's not fatal for the app.

- Nick

Trying to use the demo system this weekend results in this error

with

every market stock buy...

"Could not value this contract at this time"

Getting same here trying to place orders on
futures contracts.