Hello,
i have a win32 DLL, written in c++.
I wrote a .net wrapper for this DLL.
Then i copied this wrapper.dll (.net 2.0 assembly) to WL6 main folder.
Then created a strategy, using this wrapper namespace.
Within WL-Script derived class, i create a new instance of this wrapper
and call one of its function.
I can compile this without errors and i can execute this, without errors.

Now the problem: When i close WL6, some essential DLL functions obviously not called,
like ExitInstance. It seems like wrapper is "brutally" killed on shutdown.

This DLL can run in various environments. It operates as DLL as well as COM
and also can be used in .NET 2.0 - .NET 4.0 projects without any problems
(those projects allow to import DLL having a COM interface, which is not possible with WL6).


Can anyone help me, what to do in order to undload DLL correctly ?
Thank you

5 hours of support for your product cost nearly three times the product's price. You've been selling it for several years, advertising it on our forums a couple of times, requesting support in our support portal and forums. It's an open question how would it be possible to offer continuous support for your product among WL4 users w/o being a customer. It's a question how does WL6 run when your trial expired long ago and prolongation was refused (for a reason).

This question is not new, we tried to help in a ticket in the past. It's interesting why it is considered that our team should provide free support to a paid software vendor? Just my opinion.

Hello Eugene,
i remember you tried to help but i never got definite help
what to do. Finally i had to figure out myself how to load a COM / DLL.

So, your support was limited. I don't understand your arguments or surprise
about my expectations you to help, as my product can bring some more customer for you,
as my tool is an interface for IB.
Just my opinion.

Sorry can't greet you (Jack Torrance/Chinaski aren't real names),

An IB interface could bring us customers interested in automatic execution but there's hardly a way such tool could be announced on our site, because obviously, this would go against Fidelity's business interests. Otherwise I would have finished a fully integrated, 100% .NET IB broker provider for WL5 long ago.

I see. Thought WL 6 is a general Analsysis software
which can be bought as idependently from Fidelity.

I have customers ask me for connecting WL with IB.
This was possible with WL 4 but WL .NET does not work with my dll, TWSLink, perfectly.
All i can say is: It works in many environments/applications, among others
VB.NET, c#.NET, without problems.
Now, i am convinced,WL is not intended to be used with IB.
Thank you.

For legacy WLD customers there was (is) a free IB broker adapter, and for everyone else there was (when it was available) a 3rd party broker adapter, IBData2. They covered the needs of our customers. Things have changed although virtually nothing stops motivated programmers from developing a broker provider for WL6. (With IB in partcular, there are several different ways to skin a cat.)

If i sell a unit i get EUR 99. If you sell a unit, you get $ 500 or $ 700.
Right now, i have a customer who is testing software to use for his strategies.
Currently he checks out WL6 pro. His broker is IB.
Its only an idea, but you if can debug WL, you may could checkout why TWSLink is terminated
instead of being unloaded correctly, when WL is closed.

If he's a U.S. resident (and it appears so because I have a good idea whom you're talking about), then in order to be entitled to use WLP6 and qualify for manual/automatic order placement, Fidelity has to become his broker so to say.

Wish I could help but w.r.t. your last suggestion but I couldn't do that debugging. Nevertheless, my penultimate reply was to give a hint: move the core of your library to .NET because pure .NET would allow smooth integration.

His Broker is IB. Now he needs a platform to implement his strategy.
He is currently in a kind of validation process. So far i understood he is using
a WL evaluation.

You can call into win32 API from .NET. No problems to do this, regardless, if .NET 2.0 - .NET 4.0, VB, c#.
Only a marshalling challenge.
Changing core to .NET is simply too much as it would corrupt the whole concept: having one interface which
can be used nearly everywhere to connect to IB (1 : n interface). Sometimes a wrapper adjusts calls from other environments like perl or python. The core remains a win32 DLL.
For WL, i tried with .NET 2.0 wrapper - .NET 3.5 wrapper.It works during runtime but seems to "kill" DLL on closing.

if you can't debug, well, it makes no sense to proceed here. My hope was to extend portfolio of applications
compatible with my DLL and to bring YOU more customers as i am a selfless christ.

QUOTE:
An IB interface could bring us customers interested in automatic execution but there's hardly a way such tool could be announced on our site, because obviously, this would go against Fidelity's business interests. Otherwise I would have finished a fully integrated, 100% .NET IB broker provider for WL5 long ago.

I fully understand this in regard to WLP clients. But what about WLD users? We would like to connect to a broker, too. I can send orders to my broker anyway from within the strategy code, so I dont see why Fidelity does not give away the API doc to WLD users.

Probably because Fidelity's vision of WLD as a "Technical Analysis Application" is imprinted under Home > About box.

Nonetheless, not only can you send orders from a Strategy but it's possible to build a broker provider smoothly integrated in WLD6 by inheriting from an interface.

QUOTE:
Nonetheless, not only can you send orders from a Strategy but it's possible to build a broker provider smoothly integrated in WLD6 by inheriting from an interface.

If only there were an example for this.

I have been a WLD 4&5&6 user for a long time and I would like to be able to link it with my broker (IB). I am also a user of other platforms (NinjaTrader and AmiBroker) but I prefer WLD for a lot of reasons.

However, I'll probably be forced to not renew my WLD subscription if I am not able to connect your program with my broker in an appropriate manner (not from the code of the strategies, which is a cumbersome option, but using the much more powerful Broker Adapter API that offers WLD that allows to use all of the program features, some of which are essential for me).

I have a medium knowledge of .NET programming, but the task of reverse engineering the API is risky at best in terms of results and very time consuming. Time which I do not have. Perhaps with an example implementation of a Broker Adapter or with a few tips on how to do this task i could make it work by reducing the time required ...

It is extremely frustrating not being able to use WLD, the trading program that I like most, because i'm not able to connect to my broker. This renders it unusable for me.

Also I think that it makes no sense to provide the API and not provide its documentation. Fidelity is wrong with this posture. I think WLD has a huge potential that is being wasted for the lack of this feature. WLD could have a LOT more of users if this problem was solved.

Agreed, an example of the Broker API usage would be helpful but it doesn't exist.

Carlos (festipower),

I stumbled onto this thread and just wanted to let you know that recently, a 3rd party has created a solution for getting static/streaming data and trading with IB using WL Developer 6 (not Wealth-Lab Pro):

http://ib-automated-trading.com/