I solved this problem - it was hidden in my own code. The reason for it was that during full chart updating were updated both axes division value (custom step) and ranges. But on timer (in worker thread) were updated only ranges. So there was a situation when the chart was forced to repaint yourself with very big ranges and small division value (if the timer ticks when the values already changed but not applied to axes yet) - it takes a lot of time. I added division value updating in timer operations, and everything works fine. Thank you for attention.

Yes, I use nChartControl1.Document.Unlock(). Unfortunately I cannot provide demo-project at this time because demo-project that I tried to create works without any problems. And of course I'm not able to send you the whole our project. Maybe I will able to do it later. Thank you.

Hi Ereona,

Do you use:

nChartControl1.Document.Lock();

somewhere in your code - if this is the case you need to unlock the document after you're done with modifications using:

nChartControl1.Document.Unlock();

Can you send us an app replicating this program?

Best Regards,
Nevron Support Team

Hello.
I have NChartControl and access to it from different threads. I noticed that if I access to chart control from any worker thread during it's repainting in main thread the repainting is too long (over one minute) whereas repainting without other thread's intervention lasts less than one second. By the way the application hangs in this minute. And I get a message from MS Visual Studio "ContextSwitchDeadlock Was Detected". If I break all processes I see that the main thread is in NChartControl.OnPaint() method and the worker thread is waiting for NChartControl.Document.Lock(). Why the other thread delays repainting? How to avoid it?