User (Legacy) Posted September 16, 2003 Report Share Posted September 16, 2003 - Seems to happen less often when using MainClient - Seems to happen less often on XP than on 2000 - Will *not* occur if a single chart is displayed on an HTML page before the multiple charts are displayed. If the multiple charts are displayed first, it crashes. - Only seems to occur if two charts are initializing at the same time. Matt. Link to comment Share on other sites More sharing options...
Software FX Posted September 19, 2003 Report Share Posted September 19, 2003 Hello, This behavior has been reproduced and is currently with Development. JT Tech. Support "Matthew Mastracci" <matt@aclaro.com> wrote in message news:CQHB$jGfDHA.1484@WEBSERVER1... > - Seems to happen less often when using MainClient > - Seems to happen less often on XP than on 2000 > - Will *not* occur if a single chart is displayed on an HTML page > before the multiple charts are displayed. If the multiple charts are > displayed first, it crashes. > - Only seems to occur if two charts are initializing at the same time. > > Matt. > 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:CQHB$jGfDHA.1484@WEBSERVER1... > - Seems to happen less often when using MainClient > - Seems to happen less often on XP than on 2000 > - Will *not* occur if a single chart is displayed on an HTML page > before the multiple charts are displayed. If the multiple charts are > displayed first, it crashes. > - Only seems to occur if two charts are initializing at the same time. > > Matt. > Link to comment Share on other sites More sharing options...
User (Legacy) Posted October 15, 2003 Author Report Share Posted October 15, 2003 It's quite likely that the problem is within the .NET framework itself. It seems as if the framework is deadlocked within the WebRequest class itself. I'm wondering if the .NET remote assembly loader uses the WebRequest classes to load its assemblies in a way that might cause it to lock a resource. Have you reported the bug to Microsoft? Perhaps with enough people reporting the issue, they may look at it for framework 1.2. Matt. SoftwareFX Support wrote: > 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. > Link to comment Share on other sites More sharing options...
User (Legacy) Posted October 15, 2003 Author Report Share Posted October 15, 2003 It's quite likely that the problem is within the .NET framework itself. It seems as if the framework is deadlocked within the WebRequest class itself. I'm wondering if the .NET remote assembly loader uses the WebRequest classes to load its assemblies in a way that might cause it to lock a resource. Perhaps I might be able to work around it by creating a downloadable ActiveX control that can host a remote .NET control. It's a bit of a hack, but might work better than the "invisible chart" workaround. The other possiblility would be allowing the first chart to load, then allowing the other charts to load as they need to. Is there a method to use on a chart to signal that it has completed loading? Have you reported the bug to Microsoft? Perhaps with enough people reporting the issue, they may look at it for framework 1.2. SoftwareFX Support wrote: > 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. > Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.