The plugin is recognized and I can create a new DB with it...it will properly execute the configuration by calling method Configure(string path, IntPtr infoSitePtr) from my DLL. I've also attached Visual studio debugger and all methods except GetQuotesEx() are called by AmiBroker (breakpoints get hit)
However, when (after configuration) I click a symbol name to load the data into chart I get an exception popup, which I think is because AmiBroker can't find some method (function-name not available): https://www.screencast.com/t/iPbyLDAUaE
Could it be that AmiBroker can't find GetQuotesEx()? Or is there any other method it's trying to call? Any hints would be appreciated.
Here is how my GetQuotesEx (added inside Plugin.cs with the rest of the methods) method looks like:
[DllExport(CallingConvention = CallingConvention.Cdecl)]
public static unsafe int GetQuotesEx(string ticker, Periodicity periodicity, int lastValid, int size, Quotation* quotes, GQEContext* context)
//breakpoint is set on first line, but never hit
//code to get data here
//return from method
AmiBroker.Plugin.Plugin.Status = StatusCode.OK;
return lastValid + 1;
Forgot to mention, I've also looked at official ADK, and I have all required methods exported in my plugin:
GetPluginInfo() - works since plugin is recognized and visible under plugins
Init() - exported but empty body
Release() - exported but empty body
GetQuotesEx() - not hit
Is there any other method that gets called and could be missing in my plugin (or is AmiBroker in fact complaining about not finding GetQuotesEx())?
This project seems dead - with the last update being 5 years ago. If you really want to use C#, you may consider this commercial software http://www.dotnetforab.com/downloads. I have hired the author to do a couple of projects over the years. He is pretty competent.
@fxshrat , yeah, I agree (Greyleaf made me think I'm really using something outdated)....I think being 5 years old and still working just means that AmiBroker API was well thought and designed.
I'm still using trial version of AmiBroker so I don't think adding Matrix support will effect me for now (want to make sure I can get crypto currencies data into AmiBroker before I purchase it - didn't find any plugins that fit my needs so I'm trying to write my own one).
Any idea what would that exception mean or how can I debug it?
@PWFores, thanks, but I've already tested that and the plugin (or better cryptocompare.com API) only provides intraday (15 minutes) data for last 7 days, which is not enough to do any proper backtesting. I've also talked with author but he stopped replying, so I decided to try to make my own plugin (getting data directly from exchange).
The ideal is to never need to change the API. Properly designed API works always. Sure we can add features in backward compatible way, but general principle is that API "just works" no matter how old it is and that is the case for AmiBroker.
The exception you are getting is NOT coming from AmiBroker but from .NET thingy.
Sorry, but I don't appreciate all ".NET" framework. It shares all design flaws of Java and both .NET and Java result in bloatware.
@Tomasz, yep, good job on that (that's not always the case with other APIs).
Are you sure exception is from .NET "thingy"? I've just set up breakpoints in all of the files/methods of the plugin and none of the breakpoints gets hit before that exception pops up, which makes me think exception is not coming from plugin. Any suggestion how could I figure out where exactly exception occurs?
P.S.: I've decided to use C# since I have some experience with it, but never used C++.
There is absolutely no point in doing that as this intraday data from NSE are already available via AmiQuote:
Also, I want to reiterate that: .NET is NOT supported.
Don't use it. All those third party .NET SDKs are known to create problems with AmiBroker. Plugins should NOT be created using .NET.
.NET itself is a result of lost battle with Sun when Microsoft lost their case in court so they could not use Sun's Java. Microsoft's .NET was attempt on create "better Java" but it failed. .NET design is flawed from the very beginning (the same way as Java design is flawed).
When you write the plugin with C++ it is just say 20-100KB (yes kilobytes) and no extra runtimes needed. If you write with .NET you need 50MB of extra executables / runtime. And program that uses .NET automatically needs 100-500x more RAM than equivalent C/C++.NET is bloated beyond all measures.
Did you see our own plugins written in C++? Largest one is IB plugin (161KB) - mainly because we had to incorporate some TWS API code - it is bloated as well. But our IQFeed plugin is just 55KB, eSignal plugin 67KB, Metastock plugin 21KB, QuoteTracker plugin 23KB. They don't need any extra runtime. That is what plugins should look like. They should be tiny and not consume RAM.