MT3 API for VB.net and C# - page 3

 

Does that occour all the time or just occasionally? I notice an exception for GetHistoricalRates, in which it returns nothing if the connection to server is broken unexpectedly. Fortunately, you can exploit that exception to create a connection checking method. For example, if GetHistoricalRates() = nothing then UnknownDisconnection().

 

apologies scorpion .... was me being incredibly stupid. I forgot to login first before makign the function call. I hang my head in shame ... I'll refrain from asking you such stupid questions in future!

 

scorpion,

is there a method in the wrapped api that will allow me to get the user info like balance, equity and free margin? I can se the structure is there but there appears to be no method for retrieving this info.

thanks

steve

 

You can get user info (BriefUserInfo) by calling GetOpenTrades(). Example:

Dim info as BriefUserInfo

GetOpenTrades(info)

' Now info contains the user information.

 
scorpion:
You can get user info (BriefUserInfo) by calling GetOpenTrades(). Example: Dim info as BriefUserInfo GetOpenTrades(info) ' Now info contains the user information.

heh, can't believe I didn't see that! ... many thanks

steve

 

U're welcome Yeah unbelievable at first. The fact is that UserInfo argument is passed by reference or pointer (ByRef in VB).

 
scorpion:
You can get user info (BriefUserInfo) by calling GetOpenTrades(). Example: Dim info as BriefUserInfo GetOpenTrades(info) ' Now info contains the user information.

Hi scorpion,

I've been lurking around here for a while, picking up a few tidbits here and there as I develop my own automated trading system. I don't know about you, but I've been extremely frustrated by the lack of documentation available for the MT3 API. I've had to discover most things through trial & error...

Anyway, I've run into a problem I can't figure out. I'm using API version 3.72 (are there any other versions?) I'm accessing the DLL from a wrapper written in Perl (and C) running on cygwin. The problem is this: the BriefUserInfo struct returned by MtGetTradeRecords contains incorrect values for some of the fields, and it does so inconsistently. Some examples:

  • When I initiate pumping, I get correct values for balance, freemargin and leverage, but equity, margin and profit are 0.
  • After opening a trade, freemargin == balance (used margin is not subtracted.)
  • After closing the trade, balance, equity and margin contain the correct new values, but freemargin and profit now contain the values they should have had at the time the trade was closed.
  • Finally, if I call MtGetTrades followed by MtGetTradeRecords directly (instead of using the pumped values), everything except balance goes to 0.

Weird, huh? Besides this little issue, everything else is working just fine so far. Any ideas? Have you encountered similar behavior? Could it have something to do with the server I'm using (currently the StrategyBuilderFX demo server)? As usual, it's probably something stupid that I'm doing...but I've wasted several hours already so it can't hurt to ask.

Thanks for your help, and for this forum!

 

Hello,

I have never had these problems before. It seems that I correctly wrapped the api in vb.net.

I think your problem likely lies within the wrapper itself. It is weird enough to wrap the api in Perl and C and then run on Cygwin. As far as I know, mt3 api doesn't work well with Cygwin. The mt3 api is already in C, so no need to rewrap in C, and Perl is not the right language to do the job--the main problem might due to the structure marshalling of Perl as well. Have you check the type/structure interoperatibily of C and Perl?

Anyway, which language do you use to write the trading bot?

 

Somehow I knew you were going to say something like that. Actually, all other parts of the wrapper are working correctly, so I don't think there's a flaw in my decision to use Perl for the wrapping. It did take some doing, though...I had to dust off my C skills to deal with that "structure marshalling" and what-not between Perl and C, as I had never worked with the Perl internals before. I used a module called Inline::C, which allows one to embed C code in Perl. It was a bit tedious but quite interesting.

The reason it must run under Cygwin is so that I can compile that C code (I don't own any M$ compilers), load the DLL, as well as call Win32 API functions to create an invisible window for the pumping messages. I'm not a big fan of Windows--the rest of the system is written entirely in Perl and runs on Linux, with a web interface. The Windows portion just acts as a "proxy" for the MT server, and actually runs in a virtual machine on VMWare, on the Linux server itself. If anyone knows of a way to load a DLL and make the neccessary Win32 calls on UNIX, let me know! Perhaps something like Wine would do it? I must admit I don't know very much about such things...

I guess I'll keep working on the remaining parts of the system and hopefully the answer will come to me. I think I'll first try connecting to a different demo server, just to eliminate that possibility.

Oh, I meant to ask before--how often do you get your UPDATE_TRADES messages? I expected they would arrive quite often, particularly when a trade is open, but I'm not seeing very many, sometimes none at all. Guess this may be another bug...

Thanks again. Feel free to PM or email me if you'd like to discuss this or related things. We seem to be working towards similar goals.

 

I receive UPDATE_TRADES whenever a trade or an order is open, closed, or modified; however, you should refresh BriefUserInfo and all open trades as well whenever price changes (UPDATE_BIDASK msg?).

There two posibilities that cause error with pumping messages:

1. Win32 message loop emulated in Linux is not as same as the true Win32 message loop. A team at Mono .Net Framework had reported that they were having quite a lot of issues with message loop, so they even had to implement their own version of msg loop from scrap up.

2. It can be connection problem. Unexpected disconnection can halt message loop. The only workaround I found so far is to check if ticks keep flowing.

Reason: