darengre
23 Jan 2025, 10:39

RE: cTrader Unreliable? (Lost profits!)

firemyst said: 

Have you asked your broker why?

If so, what did they say?

Yep.  Went onto their live chat and spoke with support there, took under 2 minutes from clicking the live support button.  

They basically said there were no technical behind the scenes problems with their backend systems, and only I have access to any open positions, in the same manner as only bank account holders can affect their balance by saving or spending their hard earned cash.

darengre
22 Jan 2025, 11:58

RE: Chart rendering issue

   firemyst said: 

Hi there:

Great job with the indicator! It's one I like to use as well. 

As for your issue - don't draw a rectangle. Instead, make the rectangles a “trendline”. Same height, but use a thickness of 4 or 5 instead of 1 (to show the body). The width will expand equally in both directions. 

Keep your “wicks” trendline exactly as they are.

So the “body” will be a thick trendline, which is how I did mine.

It'll be the easiest unless you want to do something fancier with the rectangles.

 

If you want to stick with the rectangles, try something along the lines of the following. I'm not sure if it will work, but worth trying:

                Rectangle r = Chart.DrawRectangle(...);                r.HorizontalAlignment = HorizontalAlignment.Center;

Hi firemyst,

Firstly, thanks for your response and kind words, very much appreciated!

I do recall seeing somewhere on the forum someone suggesting using a trendline for their issue, and briefly looked at whether I could apply it in my code.  The problem I found is that while you can of course specify a width for the line, even going way beyond the 4-5 (I think I tried 20+ at one point!), once the line is drawn it doesn't respect the chart zoom level, so basically you can tailor the width to display correctly at say 100% zoom, but whenever you adjust said zoom during analysis, “looking left” for key levels etc., the trendline bodies stay the same width meaning they'll either all merge together if you zoom out or become tiny in comparison to the regular candles they are overlaid upon.

These are using DrawTrendline with a width of 12, at 100%, 50% and 200% zoom:

This is really why I ended up pursuing the rectangle method as I wanted the overlaid HA candles to match the size of the regular candles and behave the same as much as possible, regardless of the chart being dragged around, zoomed, etc.

So for me, while it definitely solved the “half candle on a Friday” issue, it sadly introduced other less desirable issues.

Moving on to trying your other suggestion (which had not occurred to me)!

I had to lose the “.IsFilled = true” property and add an explicit cast before VS2022 was happy and would compile it.  This produced:

This kind of removed all historic HA candles (weird in and of itself considering one drawing line was changed, none of the logic), and also gave “hollow” rectangles (expected due to IsFilled being removed) for all new live candles, and weirdly decided to make all the new rectangles start from some place off the bottom of the chart - despite the correct values being available in that context (the line that works is just commented out above).

Experimenting a bit, trying various combinations of “r” assignments as shown below didn't solve any problems without introducing others:

(Note these are all just listed here to show what I tried, I obviously didn't have all the lines present and uncommented at the same time ;) )

Some combinations allowed the HorizontalAlignment, others allows the rectangles to be filled.

I am beginning to suspect that I may just have to live with the initial Friday weekend gap causing half candles due to platform limitations.

Thanks again!

darengre
17 Dec 2024, 12:44 ( Updated at: 18 Dec 2024, 06:24 )

RE: RE: RE: .NET 6 will reach End of Support on November 12, 2024

PanagiotisCharalampous said: 

pjkellytrading said: 

PanagiotisCharalampous said: 

Hi there,

We do not have any plans to upgrade to .Net 8.0 at the moment.

Best regards,

Panagiotis

BUMP!

Hi Panagiotis,

cTrader has become my preferred algo. trading platform.

Knowing that support for .Net 8.0 will not be provided leaves little choice in progressing with c# coding of cBots for every cAlgo programmer. Sad!

Perhaps cTrader staff would reconsider this decision with enough support for the concept from the cTrader community?

Hi there,

I don't think so. Upgrading frameworks requires substantial resources that need to be redirected from other useful features. Resources are not unlimited hence if we do this, we won't do something else. Therefore we will not do this if there is no substantial value to be added to the platform. For example, at the moment we prefer to develop the R/R tool than upgrading to .Net 8.0. When we see that it's time to upgrade e.g. require some feature from the newer version, we will do it.

Best regards,

Panagiotis

This is, to put it mildly, a little disappointing.  For example, moving to .NET 8 (the latest LTS version) would seem to provide significant tangible benefits for ALL developers - a little snippet I found for consideration:

.NET 7. Further Optimizations and New Capabilities

Released in November 2022, .NET 7 builds upon the foundation of .NET 6 with the following enhancements:

• Performance Gains: Continued focus on performance, with improvements in application startup, runtime execution, and memory usage.
• C# 11 Features: Introduction of new language features that improve productivity and code readability.
• Enhanced MAUI: .NET Multi-platform App UI (MAUI) for building cross-platform applications received additional features and stability improvements.
• Cloud-Native Development: Improved support for building and deploying cloud-native applications.
• Containerization: Enhanced support for containerized applications, making it easier to deploy and manage apps in Kubernetes and other container orchestration platforms.

.NET 8. Innovating for Modern Development

.NET 8, released in November 2023, continued the trend of innovation with a focus on modern development needs:

• Advanced Performance: Even more performance optimizations, particularly in the areas of file I/O, networking, and data processing.
• Enhanced Developer Experience: Improvements in Visual Studio integration, including better debugging and profiling tools.
• New C# 12 Features: Introduction of new language constructs and syntactic sugar to reduce boilerplate code.
• AI and Machine Learning: Better integration with ML.NET and support for building AI-powered applications.
• Security Enhancements: New security features to help developers build more secure applications.

I get that it's not a trivial thing and for sure would require a decent chunk of available resources at Spotware, but surely all of the above benefits every Algo developer and Spotware themselves going forward?  Surely more than the example of the R/R tool (yes, I get there's more than being worked on!) - a bit of a strange choice in priorities in my opinion, especially given that cTrader is a great platform already and the move would bring in all the above benefits and more (e.g. truly cross-platform with one codebase, perhaps a Linux version for stability, a docker/kubernetes containerized version with all dependencies bundled - making support super easy, etc.)

The .NET 6 download page linked to from the settings in cTrader itself, also states that it requires Visual Studio 2022 (v17.0) - a version that hasn't been supported since July 2023, with as of today's date the latest being v17.12  (Full disclosure - I have not tried my current VS17.12 with .NET6 so it may work fine for algo dev, but thought I'd highlight it anyway just in case there is an issue between the versions)

Now as a developer myself (admittedly not for cAlgo until now) - I find the apparent lack of forward thinking/planning… perplexing!

Please reconsider this, as there is clearly “substantial value” already in doing so, whether any new “feature” is required or not.  Thank you for your time.