The 'do you wanna let this connection happen' dialog - problem is already
solved:

-----Mensaje original-----
De: tripack44 [mailto:no_reply@...]
Enviado el: miercoles, 03 de julio de 2002 5:08

Para: twsapi@...

Asunto: twsapi: Re: automated login


--- In twsapi@y..., Carl Erikson <carlerikson@y...> wrote:

A hack is to send keystrokes to the login window.
Pass your username as separate keystrokes. Then send
a tab key. Then send your password as separate
keystrokes. Then send a return. There is a setting
to pre-fill the username in the .ini file (sorry, no
pre-fill for the password):

[Logon]
Username=edemo

Are you sure there is no pre-fill in? I just tried it with password
field added such as the following example (:

[Logon]
Username=pfloyd5
Password=darkside

and it worked.

This is the jts.ini file in the &#92;jts directory.

-----Ursprungliche Nachricht-----
Von: grozzie2 [mailto:grozzie2@...]
Gesendet: Saturday, July 27, 2002 10:33 PM
An: twsapi@...
Betreff: Re: twsapi: Java Events-- avoinding the API

I've heard some folks have decompiled the TWS and modified the code
themselves -- long before the API became available.

The reason I kind of like an api into TWS, it bypasses all the
hassles of logins etc. A raw socket api on the server end, is going
to introduce a security layer.

With that said, there are a couple of things I'd like to see in TWS
itself, to accomodate fully external driven environments. First off,
would be great if it didn't pop up that 'do you wanna let this
connection happen' dialog, and it would be even better, if we could
run it in a 'dont even draw any windows' mode, to allow it to be run
on a totally headless system, that has no monitor, no keyboard, and
no video subsystems even loaded, aka a remote *nix setup.

Did IB make an attempt to base their API on the FIX Protocols?

I had heard of FIX many times, but this is the first time I've really
paid any attention to it, for as I was to understand only Series 7
Licensed Professionals were allowed to trade with it (automated or
otherwise).

After visiting the FIX site, it seems they have done a lot of work in
the area of Financial Transactions.



From their site:

"The Financial Information eXchange (FIX) protocol is a messaging
standard developed specifically for the real-time electronic exchange
of securities transactions. FIX is a public-domain specification
owned and maintained by FIX Protocol, Ltd. The mission of the
organization:

To improve the global trading process by defining, managing, and
promoting an open protocol for real-time, electronic communication
between industry participants, while complementing industry
standards.

The FIX protocol specification is maintained by the FIX Technical
Committee, which receives its direction from the international
Steering Committees, the Global Steering Committee, and the various
Working Groups comprised of industry participants such as fund
managers, brokers, exchanges, and vendors.
This FIX Website serves as the central repository and authority for
all specification documents, committee calendars, discussion forums,
presentations, and everything FIX. "

Techguy

I've heard some folks have decompiled the TWS and modified the code
themselves -- long before the API became available.

The reason I kind of like an api into TWS, it bypasses all the
hassles of logins etc. A raw socket api on the server end, is going
to introduce a security layer.

With that said, there are a couple of things I'd like to see in TWS
itself, to accomodate fully external driven environments. First off,
would be great if it didn't pop up that 'do you wanna let this
connection happen' dialog, and it would be even better, if we could
run it in a 'dont even draw any windows' mode, to allow it to be run
on a totally headless system, that has no monitor, no keyboard, and
no video subsystems even loaded, aka a remote *nix setup.

--- In twsapi@y..., Dion Loy <dion-y@l...> wrote:

Scott, this is very easy to do. Look up the WM_NCPAINT message in

your

Another way, that gives a lot more control, and isn't any more
difficult. Create yourself a whole brand new control, and make it
visible. During the CalcFrameLayout, place it in the right spot over
that portion of the titlebar, and set it above the title bar in the
window stack.

Now you have a new control, in the right place, with it's entirely
private set of handlers, for any kind of messages you want. If you
only want to respond to clicks, derive it from a button, and you can
put any old little bitmap in for it's pictures. Hehe, and on the
other 'extreme', derive it from an html control, and you can put a
website in it :)

Seriously though, the three windows created 'items' there are just
derivations of buttons, placed during CalcFrameLayout. If you derive
more buttons and place them there, then the buttons themselves never
have to deal with any sizing/positioning/painting or anything, you
just need to build handlers for the clicks, like any other buttons.

} Hi,
} I think this is a great idea, but whether they would
} allow "uncertified" programs to directly interact with their servers
} is unclear. The current socket interface (in the API) is only there
} as a stripped down way to control the TWS, and would likely have to
} be redesigned.
} If IB ultimately is unwilling to provide a direct interface.
} There is another solution that is even more global. Replicate the
} function of the TWS, and then create our own program/API. Since IB
} apparently uses FIX, a packet sniffer may be all that is necessary to
} get the info to implement this. Not a small project though...
}
} Andy M.
}

I've heard some folks have decompiled the TWS and modified the code
themselves -- long before the API became available.


Richard

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 ...

The stuff I have found is a non issue, for programs that dont
automatically place orders based on events. If you are just building
an orders front end, that sends orders, and displays confirms, none
of it will matter. If on the other hand, your programs are going to
act on confirms, and send NEW orders based on them, then yes,
everything I have mentioned is going to apply to all languages, and
all variations of the interfaces.

Scott - I, too, wonder if Matt at Esig has worked thru all this,

I doubt any of it will be applicable to esig. I dont think they will
be making software that actually creates orders, but rather, add an
order front end for manual orders from within esig. There is a world
of difference between a program that 'just sends an order based on an
order dialog', and one that actively manages the positions by sending
in new orders (stops, target exits, etc) based on the reports from
TWS as to the current state of the positions.

None of the race conditions and timing issues will be an issue for a
program that is not going to 'automatically' generate new orders,
without a human interaction to start the process.

This is a tricky question. On the one hand I can see your point Kent.
Having a pure programmatical socket interface would avoid the UI
issues inherent with a rapidly evolving TWS. Developers using both
low level and high level programming languages could be equally happy
with such an implementation. It would give programmers much more
control over the whole process.

On the other hand what happens to someone who wants to run their
trading interface and see the TWS updating their market positions
simultaneously? IB currently prohibits more than one connection per
account. How could they retain the security of a single connection
while at the same time providing ability to interface directly and
also synch the updates in the TWS? I'm sure many (most) would like
the benefit of seeing (verifying) their trade results in the TWS as
well as through the programmatic interface. I wonder what other
security issues might arise by having 3rd party programs interface
directly to place orders?

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

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


----- Original Message -----
From: "Marcus Jellinghaus" <Marcus_Jellinghaus@G...>
To: <twsapi@y...>
Sent: Saturday, July 27, 2002 2:22 AM
Subject: AW: twsapi: Java Events-- avoinding the API

<snip>

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

" a packet sniffer " ... He he....I dont know why this made me laugh
but it did....

Scott

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

Hi,
I think this is a great idea, but whether they would
allow "uncertified" programs to directly interact with their

servers

is unclear. The current socket interface (in the API) is only

there

as a stripped down way to control the TWS, and would likely have to
be redesigned.
If IB ultimately is unwilling to provide a direct interface.
There is another solution that is even more global. Replicate the
function of the TWS, and then create our own program/API. Since IB
apparently uses FIX, a packet sniffer may be all that is necessary

to

get the info to implement this. Not a small project though...

Andy M.

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

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


----- Original Message -----
From: "Marcus Jellinghaus" <Marcus_Jellinghaus@G...>
To: <twsapi@y...>
Sent: Saturday, July 27, 2002 2:22 AM
Subject: AW: twsapi: Java Events-- avoinding the API

<snip>

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

Hi,
I think this is a great idea, but whether they would
allow "uncertified" programs to directly interact with their servers
is unclear. The current socket interface (in the API) is only there
as a stripped down way to control the TWS, and would likely have to
be redesigned.
If IB ultimately is unwilling to provide a direct interface.
There is another solution that is even more global. Replicate the
function of the TWS, and then create our own program/API. Since IB
apparently uses FIX, a packet sniffer may be all that is necessary to
get the info to implement this. Not a small project though...

Andy M.

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

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


----- Original Message -----
From: "Marcus Jellinghaus" <Marcus_Jellinghaus@G...>
To: <twsapi@y...>
Sent: Saturday, July 27, 2002 2:22 AM
Subject: AW: twsapi: Java Events-- avoinding the API

<snip>

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

Mr. Hawkins,

Have you taken a look at TradeExecutor? It sends
bracket trades.

I realize you are a developer, but if you are just
looking for an easy solution, and not necessarily
looking to develop your own solution, here it is:



Happy Saturday!

todd
--- Bruce Hawkins <hawkinsk001@...> wrote:

To who ever created Bracket Trade,

I got to looking at the file at the TWS API site
called "bracket trade" .
How would I go about incorporating this initiating
order

Private Sub cmdLongES_Click()
Call PlaceNewOrder("BUY", 1, "ES", "FUT", "200209",
0, "", "GLOBEX", "", "MKT", 0, 0)
End Sub

and then getting the corresponding stop and target
to execute after filled with the above order?

Private Sub Command1_Click()
longtarget = longentry + ptarget
longstop = longentry - pstop
ocaID = ocaID + 1
Tws1.oca = ocaID
Call PlaceNewOrder("SELL", 1, "ES", "FUT",
"200209", 0, "", "GLOBEX", "", "LMT", longtarget, 0)
Call PlaceNewOrder("SELL", 1, "ES", "FUT",
"200209", 0, "", "GLOBEX", "", "STP", 0, longstop)

End Sub

!. I was trying to get the initial fill price of
market order into "Text5" by using

Private Sub Tws1_orderStatus (ByVal price As Single)
Text5 = price
End Sub

But I get an error.

2. Once I get the filed price of initial order in
"Text5" then

Private Sub Text5_Change ( )
something something something

I get lost after this.

Bottom line is I like the project and if I could get
an initiating order with the above stop and targets
it would be great.

Any help you can give me is appreciated,

Sincerely,

Bruce

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

开云体育

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.