johnyboy,
johnyboy wrote:
However, there is a major disadvantages to this solution: destroying/creating cursortool objects is a bad technique in the sense that in brings unnecessary memory allocation/deallocation overhead. Since the mouse cursor is a function of its position on the chart, there could be a lot of cursor changing. There will be many CursorTool as well. That will mean a lot of work for the garbage collector!
Please be aware in the code that Narcís sent a new CursorTool object is created only when the tChart.Cursor needs to be changed. New CursorTool objects are not created every time the mouse is moved over the tChart. This is not by any means the same scale of memory overhead that you may have imagined. As an aside, you might also like to bear in mind that memory allocation in .net is much faster than in native win32, as this quote from "CLR via C#" by Jeffrey Richter suggests:
"In a C-runtime heap, allocating memory for an object requires walking through a linked list of data structures. Once a large enough block is found, that block is split, and pointers in the linked-list nodes are modified to keep everything intact. For the managed heap, allocating an object simply means adding a value to a pointer - this is blazingly fast by comparison. In fact, allocating an object from the managed heap is nearly as fast as allocating memory from a thread's stack!"
You may also like to bear in mind that even if a number of CursorTool objects are created in your application due to frequent change of the tChart.Cursor, it is very unlikely that any of them will reach the GC's generation 1, again meaning a much lower memory overhead than one might at first think.
johnyboy wrote:
So my final conclusion is that this might be acceptable as a temporary workaround but I am not going to use this in production code.
I disagree that this code cannot be used in production, for the reasons I stated above.