开云体育

I'm not only thinking of myself when I suggest that separating the different
API's would be a better solution. I have been programming professionally
for 15 years so I know a little bit about how the different missions of TWS
cause complexity in the software to rise not arithmetically, but
exponentially. Plus there is the fact that as IB goes to make improvements
to the user interface of TWS, people who have MISSION CRITICAL applications
(read again: that's MISSION CRITICAL applications) are subject to more
rounds of debugging even though their interface to the application has not
changed.

My only suggestion is that they put a socket interface on their servers and
get TWS out of the loop for people who are only interested in programmable
interfaces for trading. Once a socket interface is established, an ActiveX
wrapper and a DDE wrapper could be put on top of that programmable interface
and it would be MUCH easier for IB to upgrade the socket interface
separately from TWS and vice versa. This way, everytime IB makes changes to
TWS, they don't have to worry about breaking the socket or DDE interfaces or
any of the kludges that we have written to "work around" TWS's current
idiosyncracies. Easier for them. Easier and more importantly MORE STABLE
for us.

I don't know all the details of the socket interface, but it sounds fairly
complete as is, therefore it is subject to less change going forward
especially if it were separated from TWS. In contrast, TWS is a user
interface. In user interfaces, change is the only constant. This is the
way it always is in software. API's are intended to be stable. User
interfaces are always subject to upgrades. If you're a programmer, you know
this.

I would support a group effort to request and support IB in separating the
socket interface from TWS. If we make this request of IB, we should do it
quickly because they are about to hire someone to fix the socket interface
on TWS. I suggest that those efforts would be better spent replicating the
current socket interface from TWS to their servers.

Kent

hi Grozzie & Scott:

Grozzie - I've been following your posts carefully - I'm not
anywhere in your league, but I think I understand what you've
discovered ...

Bottom line question - am I correct in assuming that the problems you
have mentioned re async responses, etc would equally impact an app
written in VB, since it is a back-end problem ?

If so, it sounds to me like you have raised a BIG RED FLAG for all of
us, regardless of the language and platform we are working on ...

Seems like IB owes us clarification and assurance of an imminent fix,
before the stampede begins ...

Scott - I, too, wonder if Matt at Esig has worked thru all this, and
found a way around the glitches. He has assured me that the Esig
implementation will be two-day, permitting orders, cancels, account
status, open position verification, and queries re pending orders.

You might want to pmail him about this (as the "head honcho" of the
group), pointing out the specific posts that bear most directly on
the concerns. If he's solved it (working, presumably, more directly
with IB's developers than us lowly hoi polloi can), then a lot of us
can consider packing up our projects, shifting over to Esig, and
using their nifty new Javascript engine to do not only analysis and
graphing, but also order entry and trade management.

FWIW, I am also aware of significant devel going on at MB trading to
provide similar interaction ... we'll see ...

Happy Hunting!

Jim


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

So what are the DLL calls?...have you deciphered all of the

classes,

and their properties, methods and events etc?

I have not even looked at the ActiveX, except a quick look

initially

when i was looking at the overview. The first thing you notice,

the

methods and properties of the ActiveX version, are identical to

those

in the C++ api, which is nothing more than a set of wrapper

functions

that hide the direct socket interface.

Hi,

to solve the non sequential events problem, you could store the events and
analyse the events with a short delay. This is already a little work around.
Your solution, of course is a "big" work-around.

Richard Foulk posted a good comment on "work-arounds":
[..]

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.

So the solution would be, to ask IB to improve it. But I?m not sure if it is
really necessary (I solved it, and I think that CarlErikson and grozzie2
solved this problem by using delays), and I?m not sure if it would mean a
total redesign of the API
Kent Rollins posted:

IB has taken a difficult route in making this one app into a User

interface,

an ActiveX interface, and a socket interface. Separate apps/libraries

would

have been a better way to go.

What is the your opinion?
Is it a really necessary? Would a solution with the current API be a "too
big work around"? Couldn?t you find a good solution?
Do you think that IB could fix it without rewriting the whole API?

Than we, as the list with 517 members should ask IB to improve it. Perhaps
they listen to us.


Marcus



-----Ursprungliche Nachricht-----
Von: realquotes101 [mailto:no_reply@...]
Gesendet: Friday, July 26, 2002 6:44 PM
An: twsapi@...
Betreff: twsapi: Java Events-- avoinding the API


Hi,
In order to avoid the non-sequential events problem with the API,
it would be useful to either try another approach or have a redundant
system to send orders/get trade status data.

Since the TWS is a java app using awt, why can't we
monitor what it's doing using
java.awt.event.AWTEventListener
and send keystrokes ets using
java.AWT.Robot?

I think AWTEventListener should be able to get the events associated
with each order (like the color based) trade status indicators. Is
that right?

Has anyone looked into this?

Thanks,
Andy


Yahoo! Groups Sponsor
ADVERTISEMENT



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



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

Hi,
In order to avoid the non-sequential events problem with the API,
it would be useful to either try another approach or have a redundant
system to send orders/get trade status data.

Since the TWS is a java app using awt, why can't we
monitor what it's doing using
java.awt.event.AWTEventListener
and send keystrokes ets using
java.AWT.Robot?

I think AWTEventListener should be able to get the events associated
with each order (like the color based) trade status indicators. Is
that right?

Has anyone looked into this?

Thanks,
Andy

I've run tests on a Win98 machine with VB ActiveX to the TWS and
haven't noticed the problems you mention. Are you doing a lot of
object creation and destruction in your code or graphical calls to
the API where you aren't freeing up the resources after use? Win98 /
95 in general don't free up resources very well in my experience.
Something else might be doing lots of redim preserves especially with
UDTs?

--- In twsapi@y..., hungerturm2000 <no_reply@y...> wrote:

Hello,

we are working on an ATS which uses signals of a neural network to
pass to the TWS via ActiveX using VB. The application runs stable

on a

Win2000 and a Win XP computer (testet with several hundred trades

in

the demo mode), but on a Win98 computer there seems to be a momory
leak (or whatever else). After about 10 trades the whole system

will

slow down and halt, but after using ctrl+alt+del the program fine

for

the next 10 Trades. But another application reports a shortage of
memory. Looking a the used memory, there doesn't seem to be an
increase. All computers are equipped with 256 MB of memory.

Has anybody else experienced such a problem??? (I know that it is
better to run the application on a Win NT based System, but there
might be a general problem with our program

thanks for your help

Bernhard

sorry, here is the updated link:



New version of TradeExecutor should be out soon.


--- evbostel <ervbo@...> wrote:

The link is not working (for me) anyway
Eric

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

The link is not working (for me) anyway
Eric

Hello,

we are working on an ATS which uses signals of a neural network to
pass to the TWS via ActiveX using VB. The application runs stable on a
Win2000 and a Win XP computer (testet with several hundred trades in
the demo mode), but on a Win98 computer there seems to be a momory
leak (or whatever else). After about 10 trades the whole system will
slow down and halt, but after using ctrl+alt+del the program fine for
the next 10 Trades. But another application reports a shortage of
memory. Looking a the used memory, there doesn't seem to be an
increase. All computers are equipped with 256 MB of memory.

Has anybody else experienced such a problem??? (I know that it is
better to run the application on a Win NT based System, but there
might be a general problem with our program

thanks for your help

Bernhard

So what are the DLL calls?...have you deciphered all of the

classes,

and their properties, methods and events etc?

I have not even looked at the ActiveX, except a quick look initially
when i was looking at the overview. The first thing you notice, the
methods and properties of the ActiveX version, are identical to those
in the C++ api, which is nothing more than a set of wrapper functions
that hide the direct socket interface.

Matt,

What is your take on the API in general ? ...your a Pro. I Want To
Hear What You Have To Say...

Your updates concerning your work at E-Signal are certainly welcome
and appreciated, but I am gonna lean on you...

I want your opinon of the API from a general perspective, especially
in light of the most recent thread, "Event Driven garbage". Obviously
this thread has generated a spirited discussion...

Are you codeing for E-Signal with the same API we are?

What Say You? Dont be shy...speak up!

Scott
Owner TWSAPI discussion forum...

--- In twsapi@y..., Matt Gundersen <mattgundersen@y...> wrote:

Hi All,

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

beta available

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

if that's

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

August. But

it's definitely coming in August.

Matt Gundersen @ eSignal

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

Grozzie...

"The ActiveX and sockets are one and the same. ActiveX is just a dll
with code to provide the sockets functionality into an ActiveX
environment."

So what are the DLL calls?...have you deciphered all of the classes,
and their properties, methods and events etc?

Does it register automatically on an API install?

What are the names of the classes...can you declare identifiers as
those types, and then create and destroy instance at will?

Please let us know what the Direct DLL calls are...

What if ANY (ha ha) properties you have found...

The methods...

And what events they expose...



Scott


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

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

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

all

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

dll

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

can

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

it

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

a

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

traps

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

LOT

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

all

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

time/effort

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

the

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

of

the pitfalls.

Hi All,

Just responding to the questions about eSignal/IB. We'll have a beta available
of IB integrated into eSignal sometime in August. It's hard to say if that's
August 1 or August 31 as we're putting out lots of new features in August. But
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 all

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 dll
with code to provide the sockets functionality into an ActiveX
environment. There is also a C++ wrapper for the sockets, so you can
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 it
out by referencing the C++ wrapper code. The socket api works, has a
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 traps
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 LOT
of special case code to accomodate it all, but, once you have it all
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 time/effort
in creating something to use this interface, take the time, read the
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 of
the pitfalls.

I thought there were 3 API's: DDE, ActiveX, and sockets. Were all 3 just
recently thrown together? And were they all in the original TWS?

Kent

How could it be feature creap? The API was just recently thrown together.

Seems more like a prototype to me.


Richard

}
} Sounds good in theory. But take a look at the title of this thread that has
} been going on for some time now.
}
} Kent
}
}

Sounds good in theory. But take a look at the title of this thread that has
been going on for some time now.

Kent

Hi all,

I am a beginer in programming ans do not exactly
understand what should be done. Hope somebody can
help.
TWS does not accept STP orders for Ftse 100 index
futures. I would like to create the spreadsheet with
conditional orders. For example if certain criteria is
met then go and buy at market (bypass stop orders)Do I
need to write a macro? In the example DDE file that
provided in IB you manually create an order.
And the other question is: Is it possible to establish
DDE link between IB and 3rd Party application without
opening and assigning ID numbers in excel.
Thanks in advance.
Artem
--- Chas Watkins <chas@...> wrote:

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

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

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.

Yes, plus it allows them to "add features" without touching the back end. I would think it's a smaller and more-contained project to add features to the client rather than fiddle with the servers.

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.

Kent