CMFCVisualManager conflicts with TeeChart?

[jti]

Some skins set by CMFCManager appear to cause TeeChart to fail after the first chart is drawn. My application is an MDI application which opens four charts.

The attached code works as expected for the Windows 2000, Office XP, Windows XP, Office 2003, Visual Studio 2005 and Visual Studio 2008 skins.

Windows 7, Office 2007 (Blue, Black, Silver, Aqua) fail - the first chart is drawn correctly but all subsequent charts fail.
The order of the plots can be changed and the first plot always works. I have found that if I add code to make the open documents tile after every chart that it will work.

The data coming into CTeeFilesView::OnInitialUpdate() alls seems correct for all the charts. However, when the code gets to CTeeFilesView::OnAfterDrawTChart() TeeCharts seem to have lost its data.

I have remvoed all theTeeChart files to make the project small enough to upload.
Put all the files from "C:\Program Files (x86)\Steema Software\TeeChart Pro v2013 ActiveX\Utilities\New VC Classes" in the JtiHorizontal\TChart directory. Then compile.

It makes no difference if one uses debug or release in the full version of the code. I have only looked at the debug version while stripping the project down.

When running the program:
Use Alt-R or Analysis->run on the menu to generate plots.

To change the skin View->Application Look->

To run with the new skin Alt-R.

It appears to me that there is some interference between TeeCharts and CMFCVisualManager with some skins, but not with others. I do not know if the fault is with my implementation, TeeCharts or CMFCVisualManager. I am using VS2012 Update 2 and TeeChart 2013. Since the problem while TeeChart's ActiveX has control, I would appreciate if Steema could offer some insight as to what the problem is.

Thanks

[Yeray]

Hi,

Note I ran your application several times and the first time I ran it I got the following error twice whenever I made it run (Alt-R):

Axis Minimum Value must be <= Maximum

Anyway, I'm trying to change the style of the application and only the Office styles seem to change something for me here, even without any chart created.
Do the styles work fine for you before running the charts (Alt-R)?
I'm in a Windows 7 x64. Tried both with the default Windows 7 and Windows Classic appearances.

[jti]

When the application first starts is should be in Windows 7 look. Running the program (ALT-R) should cause incorrect behavior in 3 of the four plots. Charts 2-4 will not plot any data. Two of the charts scales will also complain about scaling. Changing the the application look to Windows XP and re-running will will get all four charts as I expect. The application stores the Application look in your registry, so the it should start with the look that was current when the program exited. The difference in the skins is subtle in this stripped down menu only code. It is more apparent with tool bars and status bars present.

I am also running Windows 7 64 bit (SP1).

Clayton

[Yeray]

Hi Clayton,

We've done some extra tests and we could reproduce the problem with a Windows 7 x64 but not in a Windows 7 x86. This is the only difference we see between the systems. Do you have access to a Windows 7 x86 to check it?

In the x64 machine, the line of code that breaks 2 of the charts in the Windows 7 style is in the ScaleAxisT method, in TeeFilesView.cpp. Commenting it, the application runs without errors (but of course not as desired):

Code: Select all

		if (ax.GetAutomaticMinimum())
		{
			ax.SetAutomaticMinimum(false);
			iCee = floor(log10(ax.GetMinimum()));
			dMin = pow(10.0, floor(log10(ax.GetMinimum())));
			//ax.SetMinimum(pow(10.0, floor(log10(ax.GetMinimum()))));
		}

That's strange. It's like if GetMinimum returned a different value in Win 7 style than in Win XP style, but only in x64 systems?

[jti]

I am glad that you are seeing the problem.

I verified that I do not get the problem on Windows 7 Pro 32 bit, when using the Window 7 skin. I agree that there is strange behavior taking place. The fact that changing the skin of the application causes a failure took me days to track down.

I did notice on 32 bit Win 7 the OnWindowCloseall would fail, I was using TeeChart v5 for this test. Did TeeChart 2013 show this behavior?

Clayton

[Yeray]

Hi Clayton,

I verified that I do not get the problem on Windows 7 Pro 32 bit, when using the Window 7 skin. I agree that there is strange behavior taking place. The fact that changing the skin of the application causes a failure took me days to track down.

Thanks for confirming it seems to only happen in 64bit Windows. We've added this to the defect list to be further investigated.

I did notice on 32 bit Win 7 the OnWindowCloseall would fail, I was using TeeChart v5 for this test. Did TeeChart 2013 show this behavior?

We've seen the application passes through OnWindowCloseall without showing any error for us here with VS2012 abd TeeChart 2013 ActiveX. I'd suggest you to try the evaluation version to verify it.

[jti]

I have now reproduced the problem on a XP 32 bit and XP 64 bit systems, using v110_xp for the build.

The problem can move in how many times one has to put up charts without doing a tiling before it manifests itself. I am not currently able to reproduce the problem in the test code that I sent you. I think I could if I added code to dispose the four documents created and then create them again. (Putting a loop around this will probably let you turn the problem up on a 32-bit OS.)

In my full application I can delete the charts (X the upper right corner) and click on a button on the toolbar and the chart will be redrawn without tiling. This causes the chart to fill the entire client area. Once a chart fails all subsequent charts fail.

I will go out on a limb and suggest there is a memory leak that is triggered by some skins, or some skins are invading TeeChart's data area in core, or TeeChart is invading the skins area.

I have found that the axis maximum value is getting set to zero by TeeChart before my ScaleAxisT method is called, hence when the minimum is set it triggers a scaling error (Axis Minimum Value must be <= Maximum). I do not think that the scaling is the issue, but a result of a memory leak.

[Yeray]

Hi Clayton,

I'll add your observations to the ticket description, and if you can reproduce the problem in a 32bit machine with a simple example project, please don't hesitate to share it with us.

[jti]

I did verify the same problem on a Win7 - 32 bit machine using the same v110_xp build.