I'd also like to hear from Spotware some clarifications on this.
We have clarified several times how this works. What further clarifications do you need?
Best regards,
Panagiotis
Hi Panagiotis,
I don't think I've been involved in such discussions.
Could you please share these? I'd be glad to look into them.
Nevertheless, this is not only about explain how it works.
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
In short: Traders should feel confident about any time references that are made available, both in the platforms and text files.
Hi ncel01,
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
cBots work on UTC time unless explicitly requested otherwise by the programmer. This design choice has been made 13 years ago. Spotware in 2011 and Spotware in 2024 is not the same thing. So we cannot know the exact reasoning, neither we can defend it as the best. Most probably the reason was that the cBots should work as similar as possible to MT4 EAs, since back then the main target was EA developers to jump to cTrader. So I guess the main design consideration was to minimize the learning curve. Apart from that, the fact is that at the moment there are thousands of cBots running under the default UTC assumption and changing the logic would break their execution rules. Changing the current logic while keeping backwards compatibility would be a very complicated task. Hence the possibility of changing this is because 3-4 users asked for it, is almost non existent.
Best regards,
Panagiotis
Panagiotis,
I don't think you have addressed any of my concerns.
cBots work on UTC time unless explicitly requested otherwise by the programmer.
I have nothing against this, nor I am putting this into question. For execution purposes, the cBots should work on the time zone as specified in the code (UTC+0 if not defined), that will be used as Server.Time. That's clear. However, what I am/was discussing has no impact over the cBot execution, since it has nothing to do with it. See below.
What does not make sense to me:
Timestamps shown in the UI, do not seem to match the time defined by the user. It seems to me obvious that these should always match.
Text files (Log & Journal): time shown in logs is not consistent with the time mentioned for the jornal. Timestamps should remain consistent across all the .txt files that are automatically generated by cTrader. On top of this, a static reference for the time should always be used (whether this is defined by the cBot code TimeZone, or, always taken as UTC+0). Given that a .txt file will remain static and will not change when modifying the current time in the app settings, its time reference should also remain static for the sake of consistency.
I've explicitly mentioned these points in my first reply to this thread.
There are many complicated reasons that led to this implementation for which the explanation is beyond the scope of this work and my scope of work. As explained in another thread, I explain how cTrader works and not why it works the way it works. Nevertheless I will forward your point of view to the product team for consideration.
After MacOs 5.0.1 Update, crashing issue is solved.
But I am facing some other problems right now.
As you can see from 2 videos below, same code, on same pair but getting different outcomes when I print results of combobox.SelectedIndex and combobox.SelectedItem
I'd also like to hear from Spotware some clarifications on this.
We have clarified several times how this works. What further clarifications do you need?
Best regards,
Panagiotis
Hi Panagiotis,
I don't think I've been involved in such discussions.
Could you please share these? I'd be glad to look into them.
Nevertheless, this is not only about explain how it works.
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
In short: Traders should feel confident about any time references that are made available, both in the platforms and text files.
Hi ncel01,
The main question here is what considerations might have led to the current design choice, which doesn't really seem to be logical/ intuitive at all.
cBots work on UTC time unless explicitly requested otherwise by the programmer. This design choice has been made 13 years ago. Spotware in 2011 and Spotware in 2024 is not the same thing. So we cannot know the exact reasoning, neither we can defend it as the best. Most probably the reason was that the cBots should work as similar as possible to MT4 EAs, since back then the main target was EA developers to jump to cTrader. So I guess the main design consideration was to minimize the learning curve. Apart from that, the fact is that at the moment there are thousands of cBots running under the default UTC assumption and changing the logic would break their execution rules. Changing the current logic while keeping backwards compatibility would be a very complicated task. Hence the possibility of changing this is because 3-4 users asked for it, is almost non existent.
What about the SelectionStart property, any chance your team will implement it ? I managed to solve my initial problem using a lock + countdown to prevent the ObjectsUpdated event from firing when user is typing in a TextBox, but I now face a similar issue (aka the caret is jumping in front of the chars when typing).
I made a simple ValidateInput(TextBox) method to ensure the value entered in a TextBox matches some parameters: only one ‘.’ is allowed, max amount of decimal digits equals symbol.Digits, and append a ‘0’ if string starts with a ‘.’ I'm using this inside the TextChanged event handler. The method works fine, except the caret is jumping to the left if we append a ‘0’ or if the amount of decimal digits is too big. Since the text gets set in every case, I assume it really gets updated only if there is a difference between original text and filtered text, right? Here is the code, self-explanatory I believe :
private void ValidateInput(TextBox textBox)
{
string text = textBox.Text;
bool decimalPointFound = false;
int decimalDigits = 0;
StringBuilder filteredText = new();
foreach (char c in text) {
if (char.IsDigit(c)) {
if (decimalPointFound && decimalDigits < _symbol.Digits) {
filteredText.Append(c);
decimalDigits++;
} else if (!decimalPointFound) {
filteredText.Append(c);
}
} else if (c == '.' && !decimalPointFound) {
if (filteredText.Length == 0) {
filteredText.Append(0);
}
filteredText.Append(c);
decimalPointFound = true;
}
}
textBox.Text = filteredText.ToString();
textBox.SelectionStart = filteredText.Length; // Would be nice to be able to do that, effectively setting the caret position to end of text
}
Tyty, sea yah !
Hi there,
We do not have such plans at the moment, we can consider it in a later update.
Can you please provide more information about this issue e.g. steps to reproduce and some screenshots demonstrating what you are looking at?
Best regards,
Panagiotis
Hi
You can also test yourself in the backtest section; Add the Keltner Channels indicator and you will see that before starting each robot; The opening of the indicator is, for example, 50 pips away, but immediately after the start of the robot and the revelation of new candles; The opening of the indicator will quickly get closer to each other and it will show, for example, a distance of 5 pips. Photo 1 that I have attached is before the start of the robot and photo 2 shows shortly after the start of the robot. The same problem caused the robot that I wrote earlier based on this indicator and it worked correctly; It is now disabled after the recent update. I tried some similar indicators but they did not have this problem.
Thank you. We managed to reproduce this behavior and we will fix it in an upcoming update.
Thank you for your attention. Are you a member of the Ctrader technical team? How long does it take to provide the new update?
Hi there,
Yes I am. We cannot provide an ETA unfortunately. As soon as it is ready and tested, it will be released.
PanagiotisCharalampous
14 Jul 2024, 06:36
Hi there,
Can you share the code or a link where we can find this tool?
Best regards,
Panagiotis
@PanagiotisCharalampous