User (Legacy) Posted September 15, 2003 Report Share Posted September 15, 2003 <html> <head> <META http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body><object width="100%" height="100%" id="" classid="/ChartFX6/Download/ChartFX.Internet.Client.dll#SoftwareFX.ChartFX.Internet.Client.Chart" > <PARAM NAME="DataPath" VALUE="/chartfxtest/testchart.chw"> </object><style> body { margin: 0px !important; padding: 0px !important; overflow: hidden !important; } </style></body> </html> Link to comment Share on other sites More sharing options...
Software FX Posted October 13, 2003 Report Share Posted October 13, 2003 After a lot of tests assuming ChartFX was involved in the bug (e.g. loading other assemblies, loading the chart file, etc.), we created a dummy Windows Form control that does nothing else but show its Text property (code is attached). The same IE bug can be reproduced with this control (note that in the attached html we changed the assembly and class name in the object tag). If your charts do not use any extensions you can workaround the bug (as you already noticed) by creating a single invisible chart in the page that precedes your 6-chart page. If you are using extensions (Olap, Annotation, etc.) this workaround does not work because (I am guessing here) when we try to download the extension we hit the same download bug (even if a previous chart successfully downloaded the extension). It is important to note that we found a hack to bypass this issue when downloading the extensions, in our current code we download the assembly using the full name (including version). If we download the extension without including version info the bug seems to go away, the problem with this hack is that we cannot be sure that a new assembly will be downloaded when needed. We are open to any suggestions including adding a flag to force this behavior but we are not sure it will be satisfactory. It is also interesting to note that if you hit the single control page, close the browser, clear the download cache (gacutil /cdl) and then hit the multi-page control everything works fine BUT if you clear the IE cache before the multi-page control then it locks, this tells me that the bug may be related to how the .NET framework or IE download an assembly. -- Regards, JC Software FX Support "Matthew Mastracci" <matt@aclaro.com> wrote in message news:BOMYvs9eDHA.1256@WEBSERVER1... I have a testcase that results in a reproducable lockup in the IE browser each time I (and others) navigate to it. It happens on a number of different CFX.NET versions- not just a single one. The files attached to this message are the generated files of the test case. These files should be installed in a virtual directory named "/ChartFXTest". Note: the bug does not require any server-side processing to exhibit itself (the generated files are enough). To reproduce: Open a **new** browser window (the new browser window is very important). Navigate to the url "http://servername/ChartFXTest/test.html" and your browser will lock up. Note that removing all but one of the subframes will successfully render a chart. These are the conditions common to all of the computers that lock up: - Windows 2000 - Up-to-date critical updates - IE 6.0 - .NET 1.0 and 1.1 on the client I'm at a loss as to what might be causing this. Matt. WindowsControl.zip Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.