If you use ::GetConsoleWindow()'s returned HWND as a parameter, the API doesn't seem to work. Anyone know off hand what's going on internally when they initialize that API? I'm guessing it's very dependent on the Win32 message pump, and this concerns me. They do have their protocol specified in a separate document so I could write software to talk to their servers from scratch, but I would like to avoid doing this and would like to know what's going on inside this API. Comments and tips are welcome.
So I rolled out an ATL application instead of a console framework and notice that the API goes so far as to render a little widget saying it's ready into my window. I don't know if I like this at all. I guess this Genesis GTAPIB library works is that it inserts a sort of child control that is capable of getting messages routed to it for processing. When the messages are routed to it, it then determines what message it was and then calls your callbacks. This process isn't clarified in their API document at all. In a way, I guess this is okay because messages are getting serialized and the processing of the messages is thread-safe. The problem, though, is that now any operation that goes through the GTAPIB callback structure is subject to all the latency involved in handling messages. In an exceptionally fast market, this could pose real problems. I really wish Genesis made a fake executor platform available for use on the weekends/nights for API development with a test symbol for use. It's tough enough trying to make a living as a trader, but when development time is limited to the same time of the day I'm supposed to make an income, it's not so great.
I have experienced a similar problem. My goal actually is to write a Java JNI library that interfaces to the GTAPIB. Problem are the call backs. Tried to create a dummy capture window within the interfacing dll whose messaging loop runs on a separate Java thread. Used that windows HWND for the gtbCreateSession call. But the callbacks are not distributed to that window for some reason. strange. Any help would be welcome. BTW. I have a running interface to Java using a socket connection to a proxy application that has been derived fron there TestAPI B. But that's not the most efficient way to go.
Those callbacks are driven by subclassing windows in Win32, so a JNI interface would be best served by posting callback parameters and results to a synchronously accessed queue and then writing a JNI interface to pull information from that queue. Alternatively, supply your own callbacks and have a thread blocking on the communication queue that will call the callbacks as information arrives. More information on subclassing can be obtained from the platform SDK in MSDN; however, I believe what happens in that GTAPIB interface is that they have their socket events delivered to a subclassed window which then processes socket events and performance callbacks. It will never get delivered to your main window because of that subclassing. I don't use the subclassing technique much, so my description will be poor at best. I use a similar approach to minimize latency. Ultimately, though, we're going to suffer with GTAPI. I wish they'd open source their protocol, but I'm guessing they're doing this because they're reserving the right to change things.