This is the case even when a cBot is running (as shown below), suggesting that the respective cBot instance is always running on the active account, which is (obviously) not always the case.
I do not understand what is the problem. What other case could there be for local execution?
In addition to this, I don't see any explicit reference to the respective account where a cBot is running.
What do you mean by explicit reference?
Hi Panagiotis,
I do not understand what is the problem. What other case could there be for local execution?
Isn't the issue obvious? I've addressed this in the original thread. The account mentioned in the screenshot is not the account in which the cBot is running. Question #1: What's the purpose/logic behind mentioning an account other than the cBot's respective account?
What do you mean by explicit reference?
Question #2: How to easily check the account associated to a running cBot? I don't see this information explicitly (at a glance) available.
Hi ncel01,
I still don't understand
Isn't the issue obvious? I've addressed this in the original thread.
No, that is why I am asking.
The account mentioned in the screenshot is not the account in which the cBot is running.
Please provide screenshots demonstrating this
Question #1: What's the purpose/logic behind mentioning an account other than the cBot's respective account?
Cloud execution. If the cBot is executed on the cloud it could run on a different account.
Question #2: How to easily check the account associated to a running cBot? I don't see this information explicitly (at a glance) available.
I don't understand what do you want to check. It should be what you see on your screen.
Best regards,
Panagiotis
Hi Panagiotis,
The account mentioned in the screenshot is not the account in which the cBot is running. Correction: Every time a new account is selected, the cBot execution is stopped on the previous account and applied to the new account instantly, which is also not great, I'd say.
However, I noticed that every time a demo account is involved, the cBot execution is stopped and not applied to the new account. This does not make much sense to me. Shouldn't this work the other way around, for obvious reasons? To make it worse, users are not warned when switching accounts while a cBot is running, which would prevent a cBot from stopping on the current account, as well as any accidental cBot execution on the new account.
Cloud execution. If the cBot is executed on the cloud it could run on a different account.
Why is this not possible locally as well? It would be a great feature. At the moment, every cBot running on a different account requires a dedicated cTrader instance which is very resource-intensive.
Hi there,
Ok it's more clear now. I still don't see the problem. Local execution works the same way since cAlgo 1.0. Running a cBot on an account that is not the one to which cTrader is connected is not as simple as it sounds and not as obvious as it might be for your. Not all users would like such a breaking change to the way cTrader has always worked. That's why you have an option of running your cBot in an external process.
Best regards,
Panagiotis
Panagiotis,
That's clear. Thanks!
Any comments on the following?
I noticed that every time a demo account is involved, the cBot execution is stopped and not applied to the new account. This does not make much sense to me. Shouldn't this work the other way around, for obvious reasons? To make it worse, users are not warned when switching accounts while a cBot is running, which would prevent a cBot from stopping on the current account, as well as any accidental cBot execution on the new account.
This is the case even when a cBot is running (as shown below), suggesting that the respective cBot instance is always running on the active account, which is (obviously) not always the case.
I do not understand what is the problem. What other case could there be for local execution?
In addition to this, I don't see any explicit reference to the respective account where a cBot is running.
What do you mean by explicit reference?
Hi Panagiotis,
I do not understand what is the problem. What other case could there be for local execution?
Isn't the issue obvious? I've addressed this in the original thread. The account mentioned in the screenshot is not the account in which the cBot is running. Question #1: What's the purpose/logic behind mentioning an account other than the cBot's respective account?
What do you mean by explicit reference?
Question #2: How to easily check the account associated to a running cBot? I don't see this information explicitly (at a glance) available.
Hi ncel01,
I still don't understand
Isn't the issue obvious? I've addressed this in the original thread.
No, that is why I am asking.
The account mentioned in the screenshot is not the account in which the cBot is running.
Please provide screenshots demonstrating this
Question #1: What's the purpose/logic behind mentioning an account other than the cBot's respective account?
Cloud execution. If the cBot is executed on the cloud it could run on a different account.
Question #2: How to easily check the account associated to a running cBot? I don't see this information explicitly (at a glance) available.
I don't understand what do you want to check. It should be what you see on your screen.
Best regards,
Panagiotis
Hi Panagiotis,
The account mentioned in the screenshot is not the account in which the cBot is running. Correction: Every time a new account is selected, the cBot execution is stopped on the previous account and applied to the new account instantly, which is also not great, I'd say.
However, I noticed that every time a demo account is involved, the cBot execution is stopped and not applied to the new account. This does not make much sense to me. Shouldn't this work the other way around, for obvious reasons? To make it worse, users are not warned when switching accounts while a cBot is running, which would prevent a cBot from stopping on the current account, as well as any accidental cBot execution on the new account.
Cloud execution. If the cBot is executed on the cloud it could run on a different account.
Why is this not possible locally as well? It would be a great feature. At the moment, every cBot running on a different account requires a dedicated cTrader instance which is very resource-intensive.
This is the case even when a cBot is running (as shown below), suggesting that the respective cBot instance is always running on the active account, which is (obviously) not always the case.
I do not understand what is the problem. What other case could there be for local execution?
In addition to this, I don't see any explicit reference to the respective account where a cBot is running.
What do you mean by explicit reference?
Hi Panagiotis,
I do not understand what is the problem. What other case could there be for local execution?
Isn't the issue obvious? I've addressed this in the original thread. The account mentioned in the screenshot is not the account in which the cBot is running. Question #1: What's the purpose/logic behind mentioning an account other than the cBot's respective account?
What do you mean by explicit reference?
Question #2: How to easily check the account associated to a running cBot? I don't see this information explicitly (at a glance) available.
Forex symbols have consistent names across brokers, but other symbols don't.
Considering this and a multi-symbol cBot:
The possibility to add a drop-down list (to the parameters) containing all the available symbols for the current account would be very useful. As already available (by default) with every cBot instance.
Thanks.
Hi ncel01,
It is possible to use an enum as a parameter now.
Best regards,
Panagiotis
Hi Panagiotis,
I mean a dynamic drop-down list, containing all the exact symbol names for the current account. Not a static list.
Is this possible?
No this is not possible
That's a pity.
It looks like Account.Symbols is also a missing/needed property for an account.
Are there any plans to add this information to the API?
Forex symbols have consistent names across brokers, but other symbols don't.
This makes a standard (static) enum list not the most convenient/effective solution for a multi-symbol cBot.
Forex symbols have consistent names across brokers, but other symbols don't.
Considering this and a multi-symbol cBot:
The possibility to add a drop-down list (to the parameters) containing all the available symbols for the current account would be very useful. As already available (by default) with every cBot instance.
Thanks.
Hi ncel01,
It is possible to use an enum as a parameter now.
Best regards,
Panagiotis
Hi Panagiotis,
I mean a dynamic drop-down list, containing all the exact symbol names for the current account. Not a static list.
ncel01
27 Jun 2024, 15:23
( Updated at: 28 Jun 2024, 01:30 )
Hello,
Is this not yet possible?
Forex symbols have consistent names across brokers, but other symbols don't.
Considering this and a multi-symbol cBot:
The possibility to add a drop-down list (to the parameters) containing all the available symbols for the current account would be very useful. As already available (by default) with every cBot instance.
RE: RE: RE: how do you start and stop calgo on mobile? it says we we can now do it, but after turning on the bot in Cloud, i dont see the option in mobile.
Search was removed. Now you can open log file as txt files and search there
Best regards,
Panagiotis
Panagiotis,
That I've noticed. Is this considered an improvement?
With the built-in search function only the search results that matched the search were showing. There was also a filter (trading, information, warning, error).
I don't think that such features are available in notepad or similar app.
Regarding backtesting: I see the option of having a built-in search/ filter feature of much higher applicability than an option to save the log as a .txt file.
In fact, I see both these options as complementary and not as incompatible.
Please note that, among other, it is not very practical to have to open external applications to check backtest data on every backtest iteration.
I can already tell you that, in my case, this will be a huge drawback when backtesting, since I am still expecting thousands of iterations to come.
Apparently this issue is still in present in v5.0.19.
Aren't the results suppose to match 100% regardless of which data bars are selected, on condition that the same data is used in both visual/non-visual modes? Anyway, running backtests on tick data for every strategy iteration can be impractical.
It doesn't seem logical (at all) to me that checking/unchecking the visual mode box should affect results when the all the underlying data remains the same. Given this, it is highly unlikely that this is a user or cBot issue, suggesting an issue within cTrader's backtesting logic.
As you know, backtesting is crucial for traders to evaluate cBot logic accurately. Solving this inconsistency is central for traders to have confidence in their backtesting and, as a result, being confident about their cBot development process.
Last but not least, this issue has been reported multiple times. When will this finally be addressed?
ncel01
05 Jul 2024, 06:28
RE: RE: RE: RE: RE: How to easily identify the respective account for a running cBot ?
PanagiotisCharalampous said:
Panagiotis,
That's clear. Thanks!
Any comments on the following?
I noticed that every time a demo account is involved, the cBot execution is stopped and not applied to the new account.
This does not make much sense to me. Shouldn't this work the other way around, for obvious reasons?
To make it worse, users are not warned when switching accounts while a cBot is running, which would prevent a cBot from stopping on the current account, as well as any accidental cBot execution on the new account.
@ncel01