Trade Station Easy Language and NTDirect.dll Incompatible

[Blueskie]

This is from the most recent Trade Station S SDK documentation:

[line]

String or LPSTR LPSTR or char* String

While strings may be passed to and from TradeStation-compatible DLL’s, no

attempt should be made, inside a TradeStation-compatible DLL, to change the length

of a string that is an EasyLanguage variable. However, the characters of such

strings may be sorted or otherwise reorganized, as long as the overall string length

remains unchanged by the DLL.

[line]

Many of the calls via the NTDirect.dll made from the NT defined EasyLanguage functions do exactly that - they modify string length.

Using the NT interface and doing this caused some sort of corruption of the Easy Language environment for me.

What did it do?

My TS strategy would submit orders to NT from windows where there where no strategies of any kind existed. I had orders being sent to NT from my $tick charts, stock charts and any open chart window I had. It seemed to random.

I would have to restart Trade Station to re-initialize Easy Language.

If you are attempting to use the NTDirect.dll calling it from Easy Language, you can only make calls that do not change any string lengths.

If you don't thenEasy Language will be corrupted and start to behave strangely.

en

[NinjaTrader_Dierk]

imported post

Sorry, I can't follow.

Which of our ATI calls in particular do you think violate the restriction you mentioned?

[capitialistpig]

imported post

Let me preface my response - I am not a programming expert, so there is a lot I do not know.

I have time for one example. If you understand it then you might make sense of Trade Station's warning in their SDK. NTCommand returns 4 or 5 Strings, so you got a problem.

How about:

string OrderStategies(string Account)?

This returns a string that is of variable length.

(Not to mention the max string length in Easy Language is 510 characters and NT can return one much longer than that. Another little problem. )

I do know that NT returns variable string lengths for many calls andmy TS was getting screwed up from it, as per the TS warning in it's SDK.

I suspect that when TS passes an lpstr over that it has X bytes allocated to that string. If the DLL shortens or lengthens the string pointed to in EL memory then itgets messed up.

I have no clue about the EL memory model so don't even think about asking me.

I dont think that TS put that warning in there just for fun.TS dll interfaces have been around for over a decade so obviously it can be done correctly.

It appears to me that NT assumed that TS used standard dll calling practices and they do not.

I don't expect TS to change a thing, they have zero incentive to do so.

I suggest you download a copy of the TS SDK and read it. I can email you one if you can't find it. Too large to attach here.

Good Trading,

ed

[NinjaTrader_Dierk]

imported post

No there is no issue. None of the string returns by the ATI are TS variables in terms of the document below.

NT would violate the terms below if there was a function like

NTFunction(TSStringVariable)

where NT the internally modifies the string value passed in by "TSStringVariable". Howevere, there is no such NT function.

[capitalistpig]

imported post


Well if there was "no issue", my TS Strategy would execute consistently on NT without TS problems from memory corruption . It does not.

Can NT return any information to TS without modifying a TS variable directly or indirectly?

I was calling

string Orders(string account)

from EL to get "a string of order Ids of all orders that were initiated through the ATI if an account separated by '|'" as per NT documentation.

That string length is dependent on how many orders I had initiated via my EL code to NT.That means that the length of the string returned is not fixed in length. That violates the TS SDK. Also the max string size that TS can handle is 510 bytes, and NT will return longer strings than EL allows. You have not addressed that problem either.

The EL code is returning that string to a EL variable so EL can process it.

The call from TS is defined in EL as:

DefineDLLFunc: "NtDirect.dll", lpstr, "Orders", lpstr;
inputs: Account(string);

NTOrders = Orders(Account);

TS is passing NT a pointer to a string for the list of orders to be written to. TS is effectively sharing its memory space with the called DLL. How can NT return information without modifying a TS defined string? (ok as long as length is preserved but it is not).

Many of the NT calls from TS via DLL calls need to return string values with information of variable length. That memory area is shared inside TS via the pointer and thus subject to the Easy Language memory model. The changing of that string length, which NT must do return information, is what screws things up. The EL memory just does not make allowances for that.

I suspect TS is using old school null terminated strings internally, which is not a robust method of memory management. Very old school.COM calling. It would explain the restrictions as outlined in the TS SDK.

Please post a non-trival Easy Language Strategy that executes and manages orders on NT and show me wrong. I could not get my TS strategy to workand traced down the problem to NT violating the TS DDL compatibility rules. The TS strategy would become unstable after making any calls returning a modified string, like Orders above. It would require me restarting TS to clear the problem. I would like that time not to have been wasted.

Have a great weekend,

ed

[NinjaTrader_Dierk]

imported post

Memory for string returned by NT ATI is managed by NT and not by TS. TS SDK docs reflect on memory managed by TS (and not the third party app like NT).

Any string returned by NT ATI is located at the same static memory buffer (managed by the NT ATI) and thus is overwritten on each and every call which returns a string. To get around this (in case you need to save the return string) I suggest copying is to a TS variable (by assigning) and thus copy the content of the NT ATI managed memory to a TS managed memory.

To make sure it really (!) gets copied from NT managed memory to TS managed memory you could try something like:
myELVariable = NTOrders(account) + "some dummy string";

This will force TS to allocate it's own memory, assign it to myELVariable and copy the content of the static NT ATI buffer to it.

Also: Where did you find the limitation that DLL managed strings only can 510 chars long?

[NinjaTrader_Dierk]

imported post

Let's try to clarify:
- strings passed in from TS to NT ATI are not an issue here, since NT ATI will not change them
- a potential source of problems are the strings returned by NT ATI

As stated below, NT ATI only maintains one static memory buffer for returned strings which will be overwritten on each NT ATI call which returns a string. A potential source of problems now could be that TS tries to free the memory associated to a string returned from NT ATI, which in fact is the NT ATI internal static memory buffer.

On researching this issue I came across the popular GlobalVariables DLL which appears to allocate memory for the returned string on each call. This now makes be believe, that TS will free the memory returned by a DLL call.

Consequently I implemented 2 additional NT ATI calls:
- SetAllocReturnString(int value): value = 0, old behaviour, where the static return buffer is used and value = 1, new behaviour, where for each returned string a new memory buffer is allocated
- SetMaxReturnStringLength(int maxLength): which can be used to limit the max length of a returned string

These new ATI calls now are added to the EL wrapper function like NTOrders which return a string.

Please:
- terminate NT and TS
- uninstall NT via control panel
- install custom build from here: http://www.ninjatrader-support.com/n...Install.TS.msi
- import new EL wrapper into TS <install>/bin/AutoTrade/NINJATRADER.ELD

Please let us know how it goes. In case you don't experience problems we would make a permanent solution. One potential problem now could be that NT keeps consuming memory, since its returned string are not freed by TS as expected.

Thanks

[capitalistpig]

imported post

Kewl. Thanks, I will try that.

It is unfortunate that TS the EasyLanguage interpeteris not using a modern memory model.

The limitation of string size in Easy Language - 510 bytes. That alone tells me that there is a problem. Smells like legacy code to me. Hold over from the 16 bit TS days?

Knowing TS, I suspect the Easy Language interpreter language itself has not been re-written despite the fact the rest of TS is now C++ .

Thanks for your help.

ed

[NinjaTrader_Dierk]

imported post

Great, you're welcome.

Please try to challenge the new approach and try to find out if TS frees the memory allocated for strings returned by NT API calls.

Also: Please let me know if you find a definite answer to this question somewhere in the docs or in e.g. in TS forum. I didn't...

[NinjaTrader_Dierk]

imported post

Also, on the 510 char limitation for strings: Do you have a doc reference at hand? I could not find anything, but would like to find some "official" acknowledgement.

Thanks in advance.