GRT00: Neoticker does also support scripting languanges like vbscript, javascript or delphiscript (besides full-fledged languages like C++ or .NET etc.). You will have to rewrite your strategy to adapt it to the Neoticker architecture tho.
You need to write your code to support your broker's TT infrastructure and backoffice systems. TT infrastructure is comprised of numerous servers utilizing internet or fix etc. fill servers, price servers exchange specific.
Interesting post and I think I should post an answer here as NeoTicker was mentioned. VBA is an embedded language. Applications supporting VBA must be registered with a 3rd party who now owns VBA to license VBA integration on a per node basis. I assume the app you are using is either Excel or Word ... as most companies will refuse to integrate VBA on the terms of that 3rd party. Ok, back to what you are looking for - it is NOT vba integration you are looking for. You are asking for minimal changes to your code and that can route orders to the right place. Is that what you are looking for?
I normally use a tool which is called VisualChart that allows me to run .vba trading systems, but it is not an automated trading platform: http://www.visualchart.com http://www.visualchart.com/vchart4setup.exe The 2 things I´m asking for is either: a) Another charting platform that allows me to run .vba trading systems and also automatice them. or b) Trying to integrate VisualChart (where I run the vba trading system to an automated trading platform, or to some API or adaptor they could have. I think I have to recode my trading system to adapt it to any API´s.
You are still confused about what your .vba code is. They are not independent executable code. They must run within the context provided by the host application.
Your best alternative would be finding a way to send orders from your vba code to an external interface whenever your system generated an order/signal. Such code changes can vary in complexity.
Ok. Thank you. I will try to contact Trading Technologies to ask for their API´s or their FIX Adaptor.
You don't want the TT FIX adapter - the API will be fine. By far your best option as I see it is to use a minimal Excel front-end with your VBA code running in the background. Excel is not optimal from a stability point of view but if you keep interaction with sheet formulas etc to a minimum it will be fast enough for your needs. And TT API is compatible with Excel so it ticks all of your boxes. I suspect your response to this will be "not sure I want to use Excel" because it's not stable or quick enough. But the best way to improve that is to learn a new code language and compile your code properly. In the end, for the best solutions, there are no short-cuts. We have just re-written our code from Excel/vba to .NET for the same reason. And we had no skills in .Net at all 6 months ago.
I´ve been looking for translating my code to vb.net, it seems is not very different from vba but it will take a lot of time to find mistakes, test it and to be 100% sure there will not be any problems. Do you have any start point to start learning it?. There are lots of guides out there but since you´ve done this before could you please tell me which guide helped you more? Anyways I don´t lose much if I decide to try the FIX adaptor from TT one month and decide if it suits my needs. I can´t be waiting the 2, or 4, months that translating and testing again my code will last.
I hear you - delays are frustrating but I warn you that implementing your first auto-trading system will take WAAAYY longer than you expect no matter what. No recommendations for VB.NET - we used lots of googles to find articles on topics that we needed. Learned by doing. And stop obsessing about TT FIX - you don't need it as you are not sending your orders to TT via FIX. The TT API does everything you need.