Jiri
31 May 2022, 12:57

RE: RE:

amusleh said:

Jiri said:

Hi! Any update? Is this a high priority? There are many users worried at this point, please give me something that I can use to calm them down and ensure it will be working again in the near future.

Hi,

It's high priority and this change will take effect on future releases of cTrader, I can't give you any exact ETA but you can expect it on next couple of weeks.

Glad to hear that, much appreciated!

Jiri
30 May 2022, 10:33

Hi! Any update? Is this a high priority? There are many users worried at this point, please give me something that I can use to calm them down and ensure it will be working again in the near future.

Jiri
27 May 2022, 10:46

RE:

amusleh said:

Hi,

To build an indicator with source code by using dotnet CLI you can use: 

dotnet build -p:IncludeSource=True

It's not documented anywhere yet, we will add it on Automate API documentation.

Thank you!

Jiri
27 May 2022, 10:38

On my end, it fixed implicit usings but not comments in the .csproj. Please, try the project below.

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<TargetFramework>net6.0</TargetFramework>
		<ImplicitUsings>enable</ImplicitUsings>
		<!--<LangVersion>latest</LangVersion>-->
	</PropertyGroup>

	<ItemGroup>
		<PackageReference Include="cTrader.Automate" Version="1.*" />
	</ItemGroup>

</Project>

using cAlgo.API;

namespace cAlgo
{
    [Indicator(AccessRights = AccessRights.None)]
    public class ErrorCT0001 : Indicator
    {
        protected override void Initialize()
        {
            Print($"The PI value is '{Math.PI}'.");
        }

        public override void Calculate(int index) { }
    }
}

Jiri
27 May 2022, 10:14

I have noticed this as well, it's acting as if the canvas is having transparent background which makes it capture mouse events. You can set IsHitTestVisible to false to fix that but that will affect all the child items which might not be desirable. Setting the BackgroundColor to null does not help.

Jiri
27 May 2022, 09:56

Thanks for sharing this with me but it's not fixing the Error CT0001. Furthermore, I asked if it's possible to control whether the dotnet build should include the source code or not by using build properties passed as a parameter.

Amusleh, if you don't have an answer then let me know. I feel like many of my questions are being ignored making me repeat the same question multiple times hoping for an answer. I would highly appreciate it if we can make the communication more efficient.

Jiri
26 May 2022, 20:18

RE:

amusleh said:

Hi,

We discussed this and we are considering to change this behavior, but we can't make any promise.

Any estimation on when will you know the final verdict? Is it considered in the upcoming version, if so what is the ETA?

Jiri
25 May 2022, 13:28 ( Updated at: 25 May 2022, 13:38 )

I am not asking you to remove it, I am asking you to add the condition back in so my products can continue to work.

Please, can you explain why there needs to be the parameter type check for all the classes inheriting from the Indicator despite not being decorated with the IndicatorAttribute, why the change is required and can't be reverted?

Jiri
25 May 2022, 13:03

It was never supported, parameter have a list of supported types, and you can't use other types except them for parameters.

It was supported, how else would I build indicators that way which are working perfectly fine (prior 4.2) and are still used by hundreds of cTrader users.

You are misusing parameter attribute, it's meant to be used for showing a parameter on indicator/cBot parameters window, it's linked to cTrader UI and you can't use any object you want to as a parameter.

That applies to public indicators with IndicatorAttribute that are supposed to be shown in the UI, then it makes sense to have limited types supported only. If the indicator is not decorated with the IndicatorAttribute, whether it’s public, internal, or private, it is not exposed to the UI, and there is no need for the parameter type limitation. Using the ParameterAttribute is the only way to populate properties in the constructor by using the GetIndicator method and passing parameters into it. Which is how I built my indicators that were working for years without a single problem.

This is and was our design, you can't blame us for your misuse of API. The way you used Parameter attribute was not correct, and you were exploiting a bug on parameter type validation. You were exploiting a bug on API and when it got fixed now you are complaining why we imposed new limitation?

Are you serious about this?! I used the API as it was delivered to me. If I blame you for anything then it's for making changes for no reason that breaks almost every product I have made for this community and for you being so arrogant and unwilling to do anything about it.

I have no idea what's internal indicator

Here you can learn about internal modifier, what it is and why to use them. I have mentioned it numerous times, there are accessibility and OOP reasons for it. I don't see why I should be limiting myself to certain design patterns only.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/internal

It's not a new imposed limitation, it was a bug on parameter type validation and it's now fixed. You have to use an API properly, if there was something weird possible you had to report it to us, not misuse it. We haven't imposed any new limitation, cTrader 4.2 contains some bug fixes.

The limitation wasn't there before, it wasn't mentioned anywhere as a bug, and it wasn't breaking anything. If there is no reason for the change then why make it? I would really like to know what kind of bug this change is fixing. It breaks products that are in use by hundreds of users, it’s your community and my customers that are affected.

Please, revert this change and make the parameter type check only if the indicator is public and decorated with the IndicatorAttribute as it used to be all the time! Most of these indicators are offered for free so it's not worth my time to redesign all the indicators, reinvent the wheel to get all the features I am utilizing from the Indicator class, and redistribute it to over 600 users. If you don't want to address this, then let me know so I can inform all the users about discontinuing all the products before their brokers roll to the latest version of cTrader. I am already getting angry emails from those that have rolled over to the latest version.

Jiri
24 May 2022, 13:02 ( Updated at: 24 May 2022, 14:22 )

Why is it not supported anymore, what's the reason behind it? It's more like a hidden feature that was removed if anything.

It shouldn't be supported on the first place at all, you were able to use non supported parameter type because there was a bug on validation of indicator parameters that were initialized by GetIndicator method, and now it's fixed.

You did not answer my question, why it should not be supported in the first place? Why is it marked as a bug?
 

What are other ways of passing parameters to the indicator constructor if not by decorating it with ParameterAttribute and then passing it to the GetIndicator method?

Indicator instances are created by API itself, you don't create an instance by calling the indicator constructor, so there is no way to pass an object to an indicator or cBot constructor, there was never such a feature and if you tried to find some hacks and it was working on version 4.1 there is no guarantee that it will continue to work.

You can't pass anything to an indicator or cBot before it's OnStart/Initialize method is called, this is a limitation of API and you should not try to find a workaround to bypass it.

You have to develop your cBots/Indicators by considering the API limitations, not by bypassing them.

The limitation wasn't there before so why is it introduced now? I would not call it a hack, but not going to argue about that because it's pointless.

What's the proper way of initializing internal indicators if not by using the GetIndicator?

What's an internal indicator? there should be no internal indicator, this is my first time I'm seeing an indicator inside another indicator assembly, GetIndicator method is for initializing referenced indicators not for creating new indicator class inside another indicator.

So you are saying there is no support for internal indicators anymore, right? Because this is what I am arguing about all the time - it was possible prior to 4.2! I didn't have to expose the indicator to the UI and had the freedom to work with the Indicator base class as I liked. There is no difference between having multiple indicators in a single assembly versus having them split into multiple assemblies except for accessibility which you have made unsupported with this "bug fix".
 

Because there are relations between the objects, C# is an object-oriented programming language. Can you modify the sample code in the first post using the technique you are describing? I am failing to understand the solution you are proposing.

I will change your design completely if it was on me I would not designed that indicator like that on the first place, you have to ask what you want to solve? what's the problem? then implement your solution based on limitations of your environment, what you did was a temporary hack the bypasses the environment limitations not solving the issue.

Indeed C# is an OOP language, but you are using a service that is not developed by you and it has it's own limitations.

Right, you are essentially going to functional programming and limiting OOP in this case. The code is just a sample to reproduce the issue, I bet you can imagine what it is going to be like to change complex projects utilizing the Indicator properties and functions by porting from the prior cTrader version to the current one like you did here.

To summarize it, please correct me if I am wrong. The cTrader 4.2 raised the limitations for unexplained reasons causing old algos that were working completely fine not to work anymore. These changes are marked as a bug fix for your convenience despite no issues experienced in the past and you are unwilling to take the limitation away in the upcoming version. So I am forced to redesign the majority of my indicators to follow the strict design pattern - not being able to use the Indicator base class internally with custom parameter types. Is that correct?

Jiri
24 May 2022, 10:53

RE: RE:

It's definitely a bug on cTrader 4.2 that allows you to use not support parameter type.

Why is it not supported anymore, what's the reason behind it? It's more like a hidden feature that was removed if anything.

You are using Parameter attribute in a way that is not meant to be used nor documented.

What are other ways of passing parameters to the indicator constructor if not by decorating it with ParameterAttribute and then passing it to the GetIndicator method?

And you are also using GetIndicator incorrectly, it should only be used when you are using a referenced external indicator, not an indicator that resides on your current indicator assembly.

What's the proper way of initializing internal indicators if not by using the GetIndicator?

Regarding a solution, it's very simple, change your indicator design, use API members properly, why you need another indicator inside your current indicator assembly?

Because there are relations between the objects, C# is an object-oriented programming language. Can you modify the sample code in the first post using the technique you are describing? I am failing to understand the solution you are proposing.

The problem you are trying to solve is you want to exchange data between two indicators, you can use static properties for it which is the simplest option.

I need to pass an object to an indicator in the constructor, using static variables is not acceptable.

Jiri
24 May 2022, 10:23

Hi @amusleh,

Thanks for the response. It appears to me that the prior version of cTrader was checking the parameter type only if the class was decorated with the IndicatorAttribute. This makes sense because of the rendering UI components. But if there is a non-public indicator used internally only, without the UI, why would it require the limited parameter type? It does not feel like this was a bug, everything was working as expected. Can you suggest a workaround to pass custom parameter types that would be assigned prior to the Initialize state?

Jiri
08 Mar 2021, 16:13

Looks like the copying account is opening the lowest position size possible and therefore cannot be partially closed.

Jiri
26 Aug 2020, 12:59

Adding my vote as a developer of Renko Tails. Unfortunately, the current method of loading tick data using the API is not very efficient and keeps all the data in memory, which leads to high memory usage.

Jiri
14 Aug 2020, 00:11

RE: Renko update.

valentimtkd said:

Hello people.

Today I use Renko in the national market for a platform and I see it as one of the best tools for and to do graphic analysis.

The need to include the possibility of wick would help even more and improve this platform, which is already very good.

Hi Valentim, you can use one of our indicators to see the Renko wicks. 

Jiri
10 Aug 2020, 15:01

RE:

gibetheridge said:

Can someone explain to me how to get "(Posh Trader) Renko tails" to show on the renko chart? How to install says download, double click and it will show. That doesn't work.  Old guy, not a computer wizard. thanks in advance.

Hi there, after you have installed Renko Tails, you need to attach it as an indicator to the chart and authorize your copy. Here are the steps:

1. Open a chart
2. Right-click in the chart > Indicators > Custom > [PoshTrader] Renko Tails
3. Then you just click OK and allow for permissions it asks for
4. After it loads on the chart you will be asked for User Authentication (key can be found in the confirmation email or your downloads)
5. Once successfully activated, you are all done and should see wicks on Renko chart where you have the indicator attached

Please, let me know if I can be of any further help.

Jiri
21 Jul 2020, 02:33

RE:

peseaj said:

Hi there,

I would like to suggest that the columns in the "Positions" in Tradewatch should include a percentage increase in equity as "Percent Growth" or something like that.

This will help traders focus more on the percentage growth rather than the currency value of the position.

 

Thanks.

 

I totally agree with you and added my vote. In the meantime, you could use one of my tools that show the percentage and much more.

Jiri
20 Jul 2020, 08:45

RE: Junior

afonjunior2016 said:

Good operations platform, missing the wicks (shadows) of the renko chart

Hi. We have developed an indicator to calculate the Renko wicks. You can get it here: https://poshtrader.com/items/ctrader/3749/

Jiri
23 Jun 2020, 00:33

Hi, try this: 

History.Any() ? History.Last(x => x.ClosingTime.Date < Time.Date).Balance : Account.Balance

Jiri
14 Dec 2019, 14:13 ( Updated at: 21 Dec 2023, 09:21 )

In the meantime, you could use our tool to show you the deal map in an enhanced way and it works on any chart type.

https://poshtrader.com/downloads/deal-map-ct/