Hello,
We still haven't identified a definitive cause for the problem, critical sections don't provide a robust solution. The error seems to be related the axis scale and refresh thereof under the weight of the load. Low frequency failures appear to have been avoidable here by removing fixed settings from the cycle (ie. setting those settings once at initialisation).
In the meantime a few suggestions. Some of these changes may detract from the functionality that you require in the final application though for the purposes of viewing the Chart in this sample project they tend to improve visibility.
- adding the data as an array should prove more effective.
- Setup parameters should be called as infrequently as possible (a cleardata method was added to replace the role of SetupChartSingleThreshold
- The point frequency here is very high, higher than most screens can show on a pixel per pixel basis. Optionally you can paint only the first point at an x location with Series' DrawAllPoints. That may not give you the results you require for output (the code is commmented out in the sample project).
The sample project with tests implemented has been placed in answer to your original post on the attachments newsgroup.
Regards,
Marc Meumann
Chart crashing with access violation
Hello,
I just tried the new relase (7.0.0.5) of TeeChart, and it does seem to fix the "range check" errors.
I am still getting various access violation errors though. It seems to be worse on slower systems.
On slow systems the error can happen with as few as 200 points.
Any ideas about this?
Thanks.
I just tried the new relase (7.0.0.5) of TeeChart, and it does seem to fix the "range check" errors.
I am still getting various access violation errors though. It seems to be worse on slower systems.
On slow systems the error can happen with as few as 200 points.
Any ideas about this?
Thanks.
Hello,
The underlying problem here relates to the way TeeChart is being called on the thread. TeeChart can go much faster than this without a problem. You can check that by running a test and calling TeeChart population directly instead of via the generated thread.
eg. to test, instead of calling BeginThread just run TeeChart directly:
By doing so you lose many of the characteristics you want from the thread and you'll need to kill the process externally but it should at least prove that speed itself is not the issue.
In the example project the thread is being called on a Form created Chart (out of thread). That may be the cause for any out-of-thread events such as subsequent mousemoves over the Chart provoking errors when the Chart thread is running (reproduced in tests here). As a better application fit for the TeeChart Apartment threading model 'Create' of the Chart on the thread itself should prove more robust.
Regards,
Marc Meumann
The underlying problem here relates to the way TeeChart is being called on the thread. TeeChart can go much faster than this without a problem. You can check that by running a test and calling TeeChart population directly instead of via the generated thread.
eg. to test, instead of calling BeginThread just run TeeChart directly:
Code: Select all
ThreadTest((void*)&this->m_threadParms);
In the example project the thread is being called on a Form created Chart (out of thread). That may be the cause for any out-of-thread events such as subsequent mousemoves over the Chart provoking errors when the Chart thread is running (reproduced in tests here). As a better application fit for the TeeChart Apartment threading model 'Create' of the Chart on the thread itself should prove more robust.
Regards,
Marc Meumann
Steema Support