Limitations of using DLL in Multicharts vs. Multicharts.net

I have several questions about the capabilities of Multicharts and Multicharts.net. Some background: I have had Multicharts and Multicharts.net licenses for a while now but I am just getting into writing some custom code beyond simple indicators.

Ultimately, I would like to create my own GUI that can interact with Multicharts, and run other code in the background. I opted for MultiCharts.net because it seems more powerful to write in C#, but after reading some things in the forums it seems that many things can be done in the regular Multicharts edition through the combination of Powerlanguage and DLLs. Since some of the features in Multicharts are missing in Multicharts.net, it may be advantageous to stick with regular Multicharts if possible. Additionally I am getting a jump start to my project by helping a friend code an indicator/strategy in TS, so I am assuming the more I can do in Powerlanguage, the easier it will be to port it to work with TS.

My questions are:
1. Is it possible to develop something in Multicharts.net, and save it off as a DLL to be used in Multicharts?
2. What are limitations of DLLs in regards to interacting with Multicharts and creating new windows?
3. How much effort is typically required to take something developed in Multicharts and make it work in TS, assuming it was written with portability in mind. (I have found some discussion questions about going from TS to MC, but not the other way.)

Hello FRU,

1. Unfortunately, it is not possible.
2. There are no limitations on MultiCharts side, it depends on the capacities of your PC and OS.
3. PowerLanguage is 99% compatible with EasyLanguage TS 8.x and higher, several reserved words are also different but should not be an issue to replace. Please note that we do not provide support for importing the studies written in MC to TS.

Angelina,

Thank your for your reply. This is helpful. In regards to question 1, can you explain specifically why this is not possible? If the code is written in C#, I would expect it to be able to be saved as a DLL via Visual Studio unless it specifically requires a console or form interface. Based on your response to question 2 I would expect regular Multicharts to be able to reference a DLL created from any tool. Is the issue in saving the source code as a DLL or using the DLL in Multicharts?

A DLL can be written in any programming language that allows DLL creation, including C#. But it has to be written according to the rules specified here: http://www.TS.com/~/media/Fil ... on_SDK.pdf
If DLL is written in accordance with the document above, then yes, you'll be able to reference it from the regular MC.

2. What are limitations of DLLs in regards to interacting with Multicharts and creating new windows?

I believe the MC.Net environment is better for that sort of work although I still use standard MC for all my DLL work. I used to have my own control panel interface for MC. It was a standalone program (ie, not a DLL) but it communicated bidirectionally with my multi threaded MC DLL via Windows pipes. The reason I did this is to get around a problem with graphical window drawing if I did all the work in my DLL. Anyhow I gave up on the DLL+standalone app approach because a few times (not very often - perhaps once a month or so) it would stall MC for some reason on exit. It might have had something to do with my DLL exit code or how MC wasn't happy exiting while my DLL was running in a particular critical section of my code (I used Windows critical sections for my milt-threading work - perhaps I should have used mutexes instead). Anyway, I decided to simplify things and now use a control panel drawn in a detached MC window. Button actions are processed using the built-in mouse events feature, and global variables to communicate with the main study bidirectionally. If you are just doing computations a simple DLL should be fine with standard MC. If the computations take a very long time it would be better to multi thread the DLL so the function can be called asynchronously, and implement a separate function to check when the results are ready to be retrieved. If you are going to draw your own windows/graphics in the DLL then take care. I think MC.Net is better suited for that kind of work but I will let others comment further on that.