Sorry I meant 253. Symbols in group 253 are skipped when you do GetTickerList OLE call and that is what AmiQuote uses to get symbol list.
I must have a setting wrong somewhere or missing an important piece of code because when I create a composite symbol using AddToComposite() the composite symbol gets placed into Group 0 and not Group 253. Here is the code saving the composite symbol. The result always gets placed in Group 0.
SetCustomBacktestProc(""); // Only use code from this AFL
if (Action == actionPortfolio) {
bo = GetBacktesterObject();
bo.Backtest();
//--- Save equity curve (C = equity, L = Cash)
if (SaveResults) AddToComposite(bo.EquityArray, "~" + "Testing", "X", atcFlagDeleteValues|atcFlagEnableInPortfolio);
}
What do I need to change to get the composite symbol created in Group 253?
Forgot to mention when I moved the composite and index symbols to Group 253 they were excluded when running AmiQuote. So my problem is how to get AddToComposite() to save the composite in group 253 instead of group 0.
As described in the manual:
You should use atcFlagCompositeGroup (or atcFlagDefaults that already includes atcFlagCompositeGroup )
Thank you. Knew I must be missing something. When I wrote the code to save the composite symbol I remember seeing something about group 253 but didn't realize that was the key to not having AmiQuote try to get data for the symbols. So thanks for the help.
I wish AddToComposite has a parameter to define new symbol's currency or a new funtion allowing to do that.
Ab=CreateObject("Broker.Application");
Stk=ab.Stocks("symbol");
Stk.Currency="GBP";
1 Like
Thank you very much for the prompt response.
Despite using Amibroker for so many years, I'm still amazed by its flexibility.
Congratulations on the excellent product you've created.
2 Likes
@Tomasz
Hi Tomasz,
Will there be a replacement for the COM object?
For example, in the form of a .NET component with extended functionality?
I've been using the COM object for about 18 months from a C# program. This C# program reads data from a data provider every 10 minutes and stores it on an SQL Server 2022. Every 10 minutes, small CSV files are created and imported into AB using the import function of the AB COM object.
This C# program then controls AB via the COM object: "Scan, Backtest, Explore..." When signals occur, AB also creates CSV files using fWrite, which are read by the C# program and then processed further. This C# program is connected to Interactive Brokers.
This works quite well. Nevertheless, an AmiBroker .NET component would be significantly easier to use.
Best regards,
Gerd
1 Like
Replacing COM by .NET component is replacing fire with a bomb. The amount of bloat that .NET brings is significant.
If anything, AmiBroker might offer REST API because that is actually lightweight solution with wide support among different languages.
10 Likes
That would indeed be a good solution.
It would open up a wide range of possibilities for me.
With limit orders, the actual number of units traded in Interactive Brokers could be adjusted in the AB system, and the AB system could react accordingly.
Importing price data should be faster than using CSV files.
The same applies to exporting signals from the AB system. I also do that with CSV files.
And... there are certainly many other possibilities.
The 6 likes you received on your answer would be interpreted as community approval.
Will something like this be coming? I fully understand that such an extension would mean many, many hours of work for you. Therefore, I'll refrain from asking when.
1 Like
Dear @Tomasz,
I hope you are doing well.
I would like to kindly request a possible enhancement to the Explore feature in AmiBroker.
At present, when Explore is executed repeatedly, the results window briefly clears and shows a blank screen before displaying the updated output. While this is understandable from a refresh perspective, it can sometimes make continuous monitoring slightly difficult due to the flickering effect.
If possible, I would respectfully suggest an improvement where:
- The existing Explore results remain visible, and
- Only the updated values or new rows are refreshed dynamically,
- Instead of clearing and redrawing the entire results window.
This would allow Explore to function more like a real-time scanner and would greatly enhance usability during live market tracking.
I truly appreciate the continuous development and improvements being made to the platform. Thank you very much for your time and consideration.
Warm regards,
akaggarwal
Yes, I was thinking along these lines already. The devil is in the details. One solution would be kind of "double buffering", so the output is swapped immediately once explore is complete (this will eliminate most of the flicker).
The other solution would be somehow running only selected symbols (that changed in the meantime) but this is very tricky because of many details such as user sorting, and the fact that you don't really know if output changes or not (because formula may depend not only on current symbol, but also on other symbol data (Foreign) and static variables, that might change), so detecting "change" is very very tricky.
1 Like
What are the MOST CRUCIAL/CRITICAL features would you like to see in REST API for your use case?
Dear @Tomasz,
Thank you very much for taking the time to explain the technical considerations — it is always appreciated.
The double-buffering approach sounds like a very balanced and practical solution. Even simply swapping the completed result set instead of clearing the window first would likely eliminate most of the flicker and make Explore feel much smoother during repeated runs.
I completely understand how complex selective symbol refreshing would be, especially with Foreign(), static variables, and sorting dependencies involved. That indeed seems very challenging to implement safely.
That’s why the buffered swap approach feels like a meaningful usability enhancement without altering the core evaluation logic. Many users who rely on Explore for rapid, repeated scans during live markets would likely benefit from this improvement.
If it is technically feasible, I believe this enhancement would be a very welcome refinement for the community.
Thank you again for continuously improving AmiBroker and for being open to suggestions.
Warm regards,
akaggarwal
@Tomasz
First, a function similar to the import function in the COM object. This would eliminate the need for CSV files. Thread-based functionality would be even better, indeed, very good.
Access to the master data. Read/write.
Scan, backtest, explore... just like in the COM object, and also the ability to open and close APX files.
As an additional feature, perhaps...
The ability to pass data about actual trading executions to the CBT, down to the last open bar. OnBuy... OnSell or similar. This would allow limit systems to be realistically represented.
In the CBT, after bo.PostProcess(), the ability to pass data to the calling program. This is precisely where my AFL writes CSV files with the signals that are further processed in the C# program.
Please note that if you think that import can be faster than from CSV file you are mistaken. NO HTTP API will ever be faster than import from file because files are extremely fast. HTTP protocol is way slower than direct file access. There are so many layers that HTTP needs to go thru to arrive to final destination. Local file access is WAY more efficient.
The ONLY reason for REST API is that it is easier to use than OLE from some languages. Not performance, not anything other than simplicity of interfacing as pretty much every language nowadays supports HTTP requests.
2 Likes
REST API is very welcome. that would solve the biggest drawback of OLE.
Would each instance have its own port number?
I agree, import parameters should be in api request that has path to data files(import format etc). files are efficient.
The most probable scheme that I am considering now is that AmiBroker would expose two ways in addition to OLE. One is named pipe (separate pipe for each process), the second is that there will be just one REST API server on one port that you would be able to ask for running AmiBroker instances and it will give you list of IDs, so you would be able to direct your requests to specific instance just by giving instance ID.
1 Like
You are visionary! 
Named pipe is very neat on windows, because I have non-ui processes, mostly python scripts in terminal, this is best/stable IPC that has worked, and again supported by every language.
This is a post from 2023 but back then I didn't go ADK/websocket way.
Even from AFL, I have been sending data to my client-app using named pipe.
if ( pipebool != "" ) {
fh = fopen( "\\\\.\\pipe\\ExtApp1", "w" );
if( fh ) {
fputs( pipebool, fh );
fclose(fh);
GuiSetText( "", uiEdit1 );
}
}