First thing I would do is use the Print statement and write output to the logging (algo) tab to see what values and such are coming through where, so you can see what's happening.
And/or using visual studio to debug to see what the values are where.
I'm not sure how you expect anyone to help you otherwise when you haven't posted any screen captures showing your back-testing settings, or describing what your back-testing settings are.
you should also post your code logic so people can see what may be going on.
Further tests with Print(DateTime.Now.ToString("HH:mm:ss.ffff") + …) & some System.Threading.Thread.Sleep calls in both an indicator & a cbot shows that making a reference, in the first OnBar call, to the .Count of a NON-DISPLAY IndicatorDataSeries (one WITHOUT a "[Output …] attribute) DOES NOT trigger the indicator to start making Calculate calls - the Calculate calls for the 200 history Bars seem only to be triggered by the first reference to the .Count of any DISPLAY IndicatorDataSeries (one WITH [Output…]) but even then, the initial zero count is returned to the cBot and incorporated into a Print buffer before the Calculates happen.
Then the OnBar pauses while the 200 or so history Calculates happen for the Bars prior to the backtest start time, then the buffer gets put into log.txt and the Log screen, and subsequent references in the first OnBar to .Count of any display or non-display IndicatorDataSeries give correct values (because all the history Calculates have been run).
It seem in we have to make 2 references in a cBot's first OnBar (when index=0) to an indicator's IndicatorDataSeries having the [Output…] clause (making it, if the indicator were run independently, a display line not just a calculated series) in order to get a proper value - is this correct and documented or is it a bug?
I know this means nothing, but I applaud your research in trying to figure it all out and am looking forward to updates.
You can run a cbot on Renko charts. However, how well it runs and performs will obviously depend if its logic is built to handle the way Renko charts work.
For example, the open price isn't fixed until the current renko bar closes.
Do you want to add something else here, maybe? What about being pragmatic?
I never said I wanted a solution not involving cBots. What I don't want is a “solution” that can be only achieved if/while a cBot is running. Can't you really understand the difference? I suggest that you read my previous reply, again.
I do understand the difference perfectly. You haven't specified this requirement until now, so you're handicapping people who are reading and wanting to help.
Please screen capture your post where you explicitly stated this requirement of not wanting a solution while a cbot is running prior to this response if you believe otherwise.
It's not here:
I don't see anything here indicating you want such a solution:
It's not here either. Even after your point 2 below, you haven't clarified. In fact, point 3 you explicitly ask how to get this info when starting a cbot:
And it's not in this response that I'm responding to.
So you're criticizing my replies of not understanding the difference between things, when somehow, you expect me to know all your ‘requirements’ that you haven't clearly stated.
Below is some sample code you can run on a forex symbol like EURJPY to demonstrate the lack of information.
The output from the log is:
Note that it doesn't say, “Nothing to Change” in the error reported, the symbol name, or anything. Just says, “invalid request”, which to me makes no sense when someone's looking for the actual error message in log files. “invalid request” can happen for any number of reasons, and means we have to keep bothering our broker to find out what and why was an “invalid request”.
Ok so at least you get a response and a message. I will suggest to the team to enhance the message.
Would you be able to suggest to them they enhance this message too in addition to the one “Nothing to change”?
This is an example where I had to write the broker because “invalid request” in the logs didn't match with what's actually happening. In this message, it says, “Nothing to amend”, but “nothing to amend” isn't printed out in the error message returned in the calgo logs.
Ok so at least you get a response and a message. I will suggest to the team to enhance the message.
I suppose the question for the team to consider is - should it even throw an error message if there's nothing to change? As opposed to, say, a warning? (depending on how the server side captures/responds to different severity levels)
firemyst
13 Dec 2024, 00:16
Would also like to include the ability to change more colors in the app for those that are vision/color impaired.
@firemyst