Search results

Yes, you can, but you need to login to Anvil when the market is open, go into Settings, then the Account tab, then the Trader sub-tab and click on Remember Password. This will put an encrypted version of your password into the .ini file. I recently forgot how to do this myself! Took me a...

Nope, no problems here...

Hi jeffweng, yes, I'm referring to Anvil.exe. I use it the same way, just to host my DLL, but I'm talking about when I close Anvil without explicitly unloading the extension DLL first. The problem I had with these methods is that the TerminateAnvilExtension() call gets called from a function...

I don't use this method anymore, but I did experiment with it for a while. How do you guys unhook from the main window when you want to close the app? The problem is if you just click close on the app, the message gets processed by the main window with your hook as part of the call chain...

Glad I could help, even in a small way. I've been meaning to do the same thing and post an example, I just haven't gotten around to it, yet. I'm sure it would be very helpful if you were to do that!

Nope, not me.

Using the code you provided, the dialog thread should be the same as the parent, even though it's non-modal. Create does not create a new thread. Don't get the MFC Create confused with the API call. Now the timer callback could be coming from another thread... I'm not 100% sure in this case.

Again, I'm not in front of my computer, but I'm pretty sure the MFC Create call does not create a new thread. This might require the dialog have a parent or owner, but I am sure that it doesn't need to be modal. MFC modal dialogs aren't even truly modal... They're implemented using the parent's...

The dialog doesn't need to be modal... I'm on the road right now so I don't have access to my code. But if you followed the examples you should be fine.

Oh, and I always forget... But is the timeout routine called from the same thread? It depends upon the framework, but in .NET, for example, the timeouts get called from a thread pool... I don't remember offhand for MFC.

And you're also using the debug build of Anvil?

I want to make sure that we're talking about the same thing. The thread that makes all of the B_ calls needs to be the hook into Anvil. You can create another thread for order management, housekeeping, whatever, but you need to post into Anvil's GUI thread for making all B_ calls, or you will...

Could you be mixing debug and release builds?

Are you processing the M_SYNC_TIME message? It provides the server time and you can use that to create an offset to adjust your local time. case M_SYNC_TIME: { FILETIME ftLocalTime; FILETIME ftServerTime; static LONGLONG llOldDifference=NULL; LONGLONG llDifference=NULL...

You can appear to "get away" with making some of the B_ calls in your worker thread, meaning everything will appear to work most of the time. But the calls aren't thread safe, so this is a risky procedure and I think you should avoid it. When I programmed my first implementation, I was...

You're welcome! Hopefully it helps. Right, the DLL contains a list of functions that get called by Anvil.exe. A DLL is simply a library of functions, not a program per se. So it can't "run" by itself, it needs to be called by some .exe file. So when you write an extension DLL, you are...

Without actually sitting in front of my development studio and walking through it myself, I can't tell you specifically what the problem is. You cannot debug a DLL without some executable loading it. That's why the development studio is asking you for an executable. Yes, you should choose...

If the error you are referring to is regarding the lack of debug information, this is just the compiler telling you that the copy of Anvil you are running wasn't compiled with debug information. It won't prevent you from loading or debugging your DLL. But make sure that if you compiled your...

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...

Here's a link to an interesting article by Paul DiLascia. It's pretty old, but the point is MFC does a whole lot under the covers that you (probably) don't even want to know! It gives an overview of how dialogs are linked together in one message pump under MFC...