ANVIL API (Assent) Developer Thread

Quote from ootbt08:

I'm wondering if anyone would have a sample dll that they would be able to share that would show the basics of hooking into Anvil and generating a few threads.
More...
Hi ootbt08,

Welcome to the thread.

If you are following the examples then your dialog is an MFC dialog, correct? When you created this dialog, it actually hooked into the main windows thread of Anvil, and MFC will gracefully unhook it as well when you shut down your application. So as far as hooking, you're good to go. All of the Anvil API commands can be executed in your dialog's methods, as each method is run in the main Anvil thread.

As for the threading, it sounds like what you want is to create some background worker threads, right? In Windows vernacular, you have two kinds of threads, "worker threads" which have no message pump, i.e. they're just basically a subroutine that runs in a separate thread until the routine exits, and "UI threads" which have a message pump and can receive messages from Windows or other threads. Note that UI threads do not require a visible window associated with them, although they can support a window, unlike worker threads.

You can use either kind of thread as a background thread. The decision point is what kind of communication do you need between threads? In my case, I tend to use background threads that are event driven, so I create a UI thread derived from CWinThread. Then you can post messages to the thread using PostThreadMessage, i.e. when the data you've subscribed to changes. To execute the API functions, you need to post a message to your main dialog (which is in the Anvil thread). If you want to do this synchronously, you will then need to wait until the routine completes. I do this using events. (It's not wise to use SendMessage across threads.)

I know this is a rather high level overview, but hopefully it will point you in the right direction. I'm not able to get to my code now, but I might be able to throw something together that I could share later today or tomorrow. I was actually thinking about writing a generic multithreaded framework that would help people get started with using multithreaded Anvil extension DLL's... It might help to see a concrete example of one implementation of multithreading and synchronization.
 
Thanks so much for the information you have shared.

[If you are following the examples then your dialog is an MFC dialog, correct? When you created this dialog, it actually hooked into the main windows thread of Anvil, and MFC will gracefully unhook it as well when you shut down your application. So as far as hooking, you're good to go. All of the Anvil API commands can be executed in your dialog's methods, as each method is run in the main Anvil thread.

If you are following the examples then your dialog is an MFC dialog, correct? When you created this dialog, it actually hooked into the main windows thread of Anvil, and MFC will gracefully unhook it as well when you shut down your application. So as far as hooking, you're good to go. All of the Anvil API commands can be executed in your dialog's methods, as each method is run in the main Anvil thread.

As for the threading, it sounds like what you want is to create some background worker threads, right? In Windows vernacular, you have two kinds of threads, "worker threads" which have no message pump, i.e. they're just basically a subroutine that runs in a separate thread until the routine exits, and "UI threads" which have a message pump and can receive messages from Windows or other threads. Note that UI threads do not require a visible window associated with them, although they can support a window, unlike worker threads.

You can use either kind of thread as a background thread. The decision point is what kind of communication do you need between threads? In my case, I tend to use background threads that are event driven, so I create a UI thread derived from CWinThread. Then you can post messages to the thread using PostThreadMessage, i.e. when the data you've subscribed to changes. To execute the API functions, you need to post a message to your main dialog (which is in the Anvil thread). If you want to do this synchronously, you will then need to wait until the routine completes. I do this using events. (It's not wise to use SendMessage across threads.)]

Yes, right now I'm using an MFC Dialog and I was getting confused as to whether I should be hooking into Anvil using SetWindowsHookEx. After reading your reply, I believe that one would use SetWindowsHookEx if they were writing an ATL dll. Right?

Also, thanks so much for the explanations of the different windows threads as it has helped me clear up things that I was a bit confused on.

I'm also going to try to create a sample app and if I get it working I'll post it out here so others can see it.

Thanks so much!!!
 
Quote from ootbt08:

Yes, right now I'm using an MFC Dialog and I was getting confused as to whether I should be hooking into Anvil using SetWindowsHookEx. After reading your reply, I believe that one would use SetWindowsHookEx if they were writing an ATL dll. Right?
More...
Right, if you're using an MFC dialog then the MFC framework hooks your dialog into the parent window's message pump. It's very convenient, because it also takes care of the cleanup. You do not need to use SetWindowsHookEx with MFC.

The first time I tried using the API I created a generic class and hooked it into the main window's message pump using SetWindowsHookEx. It's very complicated to explain, but when trying to close the main Anvil dialog without manually unloading the extension DLL first it is very difficult to unhook cleanly. (Basically you get into a situation where you're fiddling with the call stack, because the function pointer for your hook is already part of the call stack when you want to unhook!) So it would throw an exception on exit. This might not be important to you, but I'm pretty anal and it drove me nuts! The MFC implementation was far simpler.

But I'm an MFC guy, so I'm biased. I think ctarmor-et did it with SetWindowsHookEx, and he could probably give you more info regarding that implementation.
 
tjfield way is definetly more elegant than mine.

I did create one extra worker thread. I also hooked into the main anvil thread msgs queue so I can process my on user messages, like enter orders, etc

Msgs are posted into the main anvil thread when by the worker thread when it produces a trade signal. The powrker thread keep track of all the time cononsumer inidcators, like bars, avg, etc ...

I sent msgs to from my worker thread from the stock process (LAST_TRADE_SHORT)....

I'll explain in detail my design later. I have to take my daughter to piano now .... :-)
 
Once again I have to say thank you!!

The messages that tfield and ctarmor-et have posted have been extremely helpful!!!

I of course have to ask a few more questions.

1. In one of the older postings there was talk about how ATL was better to use than MFC. Dioes anyone know how much faster ATL is over MFC?

2. This questions is for ctarmor-et. I've seen that you can process 2K symbols at a time. Are your programs running on machines at Assent or offsite?
 
I personally like neither ATL or MFC, but they facilatate much fucntionality. I personally use ATL whenever I need to.

I terms of GUI, I let the ANVIL main Gui thread take care of all GUI messages, including my own windows. The worker thread(s) take care of all the algorithmic processing. I have them inter-communicate by posting messages to each other.

We had a server in Hoboken. It was fast and it worked pretty well (except for the strategy :-)
 
Hi,

I load the Anvil.exe when I run the program and get the following error.

No Debugging Information
Debugging information for 'Anvil.exe.' cannot be found or does not match. Binary was not built with debug information. Do you want to continue debugging?


I click yes and then it asks me to log into Anvil. I successfuly log into anvil and nothing happens. I was expecting a window to pop up like shown in the AnvilTrader.rc

I must be doing something wrong.

Thanks
 
Quote from _1234567891_:

Hi,

I load the Anvil.exe when I run the program and get the following error.

No Debugging Information
Debugging information for 'Anvil.exe.' cannot be found or does not match. Binary was not built with debug information. Do you want to continue debugging?


I click yes and then it asks me to log into Anvil. I successfuly log into anvil and nothing happens. I was expecting a window to pop up like shown in the AnvilTrader.rc

I must be doing something wrong.

Thanks
More...

You need to manually load the extension. Open the toolbal and opene the extension manager. The icon is towards the far right of the toolbal. Righ mouse click and load extension.

There is an automatic way to laod teh extension when you login to anvil. Open the anvil.ini and tehre should be a tag "ext" (or soemthing like that). specify the path for anvil to automatically loaf the available extensions. Internally it will ::LoadLibrary() every dll and look for the anvil apis.
 
As for ATL versus MFC, I have never used ATL so I can't comment.

For most of what you will be doing with an extension DLL, I don't think that any inefficiencies or overhead that may be present in MFC will plague you much, because in reality your DLL will probably be very lightweight.

If I need to make many arrays/maps/etc. for cross referencing, I use STL which IS faster than the MFC implementations.

This was the question to ctarmor-et, but I'll chime in: I have a server in Hoboken as well. I've been able to subscribe to roughly 1k to 2k symbols depending on the volume of the day, but the overhead in the API itself prevented me from subscribing to more in that one thread. If the API dogs down too much, the server will drop you, then you need to resubscribe. The issue wasn't bandwidth but just processing power required for the API to parse the data. To get more symbols, I would have to run multiple instances so that I could take advantage of the multiple cores.
 
You must log in or register to reply here.
Back
Top