Steema Central

Hi,

I'm using a custom control by Larcom & Young known as a "Resize" control.
Version 4.1 OCX
http://lyoung.com/

This control is placed on the form and it requires no interaction.
It automatically resizes everything on the form when the form size is changed during run time.
This allows us to stretch the form and the TChart in any direction.

What we see happening is that as long as the width of the form the TChart resides on is not much more that about 9600 pixels wide, everything is fine.
Any wider and the SetTimer API routines stop responding.
If the form is bought back to original size (or close to it) the API's resume function.

I notice that during this time all functions and routines not related to the timers work fine as do other programs that may also be running.

We also use a total of 6 custom vertical axis's - 3 on the left and 3 on the right. If any of the 3 on the right are not used, the responsiveness of the program improves. If all 3 right axis's are not being used, the responsiveness is almost normal. The use or non-use of the left axis's seem inconsequential.

I appreciate the fact that you folks are quick to respond to issues and I await your replies!
Thanks.

Hello,

tirby wrote:What we see happening is that as long as the width of the form the TChart resides on is not much more that about 9600 pixels wide, everything is fine.
Any wider and the SetTimer API routines stop responding.
If the form is bought back to original size (or close to it) the API's resume function.

Does it still happen without any Chart on the form?
I mean, have you tried to reproduce the problem out of TeeChart? Maybe this is not TeeChart related.
What are these Timers doing?

tirby wrote:We also use a total of 6 custom vertical axis's - 3 on the left and 3 on the right. If any of the 3 on the right are not used, the responsiveness of the program improves. If all 3 right axis's are not being used, the responsiveness is almost normal. The use or non-use of the left axis's seem inconsequential.

The number of custom axes in the right side seems to affect the timers, is this what you observe? Any other noticeable effect?

It would be helpful if we could reproduce the problem with a simple example project we can run as-is here.
Also, if you know the conditions where this happens, maybe you can try to reproduce the problem without one of the components. Ie, a chart with a big size set manually (and withoutLYoung control), or with a LYoung control (and without any chart).

Ok, I have determined that the Resize.Ocx has nothing to do with the issue.

I have attached a small project that demonstrates the issue.

There is some small error in my demo project, I can't seem to get all the custom axis's to show up.
But that does not appear to be an issue, so I didn't spend anymore time trying to correct it.

Please note that I'm actually using a standard VB6 timer rather than the API timer - problem is still apparent.

Note that the time count in the textbox changes the speed at which it is updated depending on the width of the form & TChart.

Let me know if I can provide any further input!
Thanks

Hi tirby,

Thanks for the example projecte and information.

tirby wrote:What we see happening is that as long as the width of the form the TChart resides on is not much more that about 9600 pixels wide, everything is fine.

First of all please notice that your example project is not using pixels but Twips. You'll see that in Form's ScaleMode property. If that was in pixels, you'd be speaking of huge forms and charts.

tirby wrote:What we see happening is that as long as the width of the form the TChart resides on is not much more that about 9600 pixels wide, everything is fine.
Any wider and the SetTimer API routines stop responding.
If the form is bought back to original size (or close to it) the API's resume function.

This is may vary according to machine's power. I can see no problem on a new powerful machine (Windows 8.1 64-bit, Intel Core i7-4771 @3.5GHz CPU, 16GB RAM, Samsung SSD 840 EVO disk and NVIDIA GeForce GTX 760 graphic card). Anyway, I suspect the problem lie in that TeeChart is not thread safe and thread tries to update TeeChart before previous repaint cycles have completed.

Drawing speed depends on many factors from the chart settings (axes grids, labels, 2D/3D, number of series, etc.) and the number of points to be drawn to the machine specifications. Some interesting tips to optimize charting performance can be found in the demos under All Features\Welcome !\Speed and also in the Real-time charting article here (it is a VCL (Delphi) article but the majority can be easily translated and applied to VB6).

Also, if what I suggested in the previous paragraph is not enough, you could try applying the asynchronous painting technique using AutoRepaint property, which is already demonstrated in the Real-time Charting article. The idea behind it is to leave the chart time enough for it to repaint before calling another repainting cycling and hence obtain a responsive chart. You'll find a simple example in my 24th November 2006 reply here.