richard

That seems to have fixed it. I had to remove and recreate the entry in the VS toolbox as well though Thanks

I'm suddenly getting System.EntryPointNotFoundException on ChartAdornment when using the chartfx designer in VS2005. Nothing has changed as far as I know and I have been using ChartFX for years. Any idea what this might be?

Thank you that seems to have fixed the problems

I have tracked down one of the problems with the template. I did this by exporting the binary template as xml and then reimporting after removing tags one at a time. The problem is with a tag called CLUSTER. If this is removed the stacking problem is solved. We didn't set this tag specifically and we can force it off before binding if this will have no other effect. Please confirm. Perhaps you can fix this bug on the next SP With regard to exceptions etc this is still a problem. You can easily replicate it on the test app by adding three checkboxes - one each for series 0,1 and 2 and setting the series visible property off. If you bind the data, show the line first then hide each of the other series one at a time followed by hiding the line there is an immediate argument out of range exception as shown on the stack trace below. at SoftwareFX.ChartFX.DataArray.get_Item(Int32 series, Int32 point) at SoftwareFX.ChartFX.15.KU(Double 26J, Double 26K) at SoftwareFX.ChartFX.17.KO(Boolean 278, Double 279, Double 27A, Double 27B, Boolean& 27C) at SoftwareFX.ChartFX.AxisBase.JP(1R 23O, Rectangle[] 23P, SetPropFlag& 23Q, 1C 23R, AxisSection& 23S) at SoftwareFX.ChartFX.AxisCollection.KA(1R 254, Rectangle[] 255, 1C 256) at SoftwareFX.ChartFX.ChartCore.EP(1R 1T1, Boolean 1T2, Boolean 1T3) at SoftwareFX.ChartFX.ChartCore.EO(1R 1SY, Rectangle& 1SZ, Int32& 1T0) at SoftwareFX.ChartFX.ChartCore.EN(PaintBar 1SV, IGraphicsEx 1SW, Rectangle& 1SX) at SoftwareFX.ChartFX.0X.OnPaint(PaintEventArgs e) at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs) at System.Windows.Forms.Control.WmPaint(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData) at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.Run(ApplicationContext context) at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun() at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel() at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine) at CFXDEMO.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81 at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart()

Update on my previous post. While the latest service pack seems to have solved the problem of an easily repeatable exception when all of the series are hidden, this problem has been replaced with a more intermittent problem in that the application usually hangs with the following CLR message The CLR has been unable to transition from COM context 0x1a0568 to COM context 0x1a06d8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Attached is a small demo program which shows the issue. On load a standard default chart is displayed. Pressing button 1 will load an embedded template which was saved as a 3 series stacked bar with an XAxis date format. Pressing button 2 will create a small table of 5 rows and 5 columns comprising data matching the template but with an extra series. The table is bound to the chart and the extra series is set as a line series but hidden. Initially all looks well with the series stacked in the order of columns in the table with colours as per the template. The check box is then used to hide/show the extra series but when this is checked the order of stacking changes and the new series is behind rather than in front of the bars. There was a further problem in that hiding all of the series resulted in an exception but this problem has disappeared on downloading the latest service pack

We are using a binary template to control the layout/appearance of a chart and are then binding the chart to a table for the data. If the table contains more series than the templates a number of strange things happen ChartFX raises an exception when the last of the series is made not visible If the chart is a mixture of bar and line the lines do not overlay the bars even though these are later in the series (ie data columns) When a non stacked series is made non visible the order of stacking of other series changes None of these problems occur if the template is not used. Is there any way of programming round this as we can't guarantee that the number of series in the template is the same as the number of series in the query