Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I've tried everything to get a dll to work, with no success whatsoever. To my knowledge, all threads about this topic are at least 3 to 4 years old, and it's difficult ti find anything really replicable on current softwares.
The problem: write a dll, for MC64, with a simple function in it, and make it work. Probably to many of you this will look like a trivial task, but whatever I did, after reading virtually every thread and manual out there, I keep getting the the error "Can't find the dll "name.dll"".
Now, the dll is where it should and moving it somewhere else is useless. I came to the conclusion that there's some compatibility issue, bitness may be an example but I made sure to compile in 64.
I can't be the only one that is having problems in doing this, so I think it would be useful to have an updated thread on the matter.
Just as a starting point, here is my code:
PL reference:
Then there are the two components of the library: a .cpp for the body of functions, and the .def file for exports.
They will look something like this.
The body:
The .def:
The header .h file completes the picture.
The thing is compiled using Visual Studio 2017 for x64 platforms. Obviously there's something wrong with this, and the library results as not found.
Is there anyone capable of showing an example of working dll source code for MC64?
Few clarifications:
The dll content is kept as simple as possible to avoid a superposition of multiple mistakes
The dll is where it should, in the installation folder
Moving it somewhere else and explicitly reference the whole path doesn't make any difference
Dlls that are officially provided by MC work properly, ELCollections is an example that I tried
The dll is needed, so, in this case, "code the PL equivalent" is not a viable solution. Just assume a dll is needed.
Can you help answer these questions from other members on NexusFi?
Yes you can, but unfortunately they are quite old, and not compatible with Visual Studio 2017, and are all in 32 bit.
You can manage to open them with the new VS, but still, simply compiling the code in x64 does't work. I've tried literally everythingwith those examples, with no success.
This is why I think an equivalent example, but newer, guaranteed to work on updated platforms, and in 64 bit, would be of great help. (not only to me I imagine)
Importing PLKit.dll is only needed if the content of PLKit.dll is needed. If the dll doesn't access TS/MC information, as in this example (simple sum of two doubles) then PLKit.dll should not be included, and I didn't not to add an extra layer of complexity,
Have you tried monitoring the MC process while it attempts to load the DLL via one of the Microsoft process tools (e.g. Process Monitor or Process Explorer; https://docs.microsoft.com/en-us/sysinternals/downloads/procmon). You should be able to attach it to a running MultiCharts instance and then enable the signal containing the DLL and see where MC THINKS the DLL is stored (it usually tries multiple places before failing).
My .02 - I'm updating my VS 2017 Community version at the moment which is taking a while unfortunately
Well, I cant really tell what's going on, but it seems like the dll is found where it is:
I can't really tell what's going on from the output, but it looks like MC achieve success in almost everything it's trying to do with the dll when doing it in the installation folder. Then it goes on trying different folders, where it can't have success because the dll it's not there.
If when your update is done you could share some code that would be immensely appreciated.
) until I've had a chance to play with VS 2017 again. You're probably not using PureBasic but I was able to get DLLs generated from both that and VS "C" code a while back.
Haven't tried recently to make sure it still works with the latest MC64 / VS 2017 combo so it will take a bit of time to see what "still works" (hopefully) - will let you know.
I recently tested the lastest version of PureBasic with MC11. Everything works well until you set a variable to threaded. Multicharts will crash on exit. This is an old problem that was never fixed. Setting the compiler to threadsafe doesn't make a difference.
I had better luck with FreePascal x64 and I stayed with that for what I was trying to do at the time.
Different issue than the one you're having (multithreading issues are NEVER fun though - been there many times...).
Assuming that the loader is actually finding the DLL file and is able to open/read it OK, the only other thing that typically happens is that the function names are being mangled (ala C++ method style) so that MC can't actually find them. Usually that's solved by declaring them with 'extern "C"' wrappers or some such. Do you know how the DLL function names are being stored/exposed? Just a thought...
I wrote a 64 bit dll a few years ago that I still call from Multicharts today. I do vaguely recall having this issue (amongst others) but I can't remember exactly what the cause was.
However, I think that one (or all) of the following fixed it.
1. Ensuring that it was compiled as 64 bit (but you've already checked that)
2. Ensuring that the .dll was registered OK.
3. Downloading and running the relevant Redistributables for VS and then recompile.
For me, I think it was 2008 and/or 2015 at the time but in your case it'll be the 2017 Redistributable. Worth a shot if you haven't already tried this.
If my addled brain ever remembers exactly what it was - apart from the above - I'll add it here.
