How to disable CancelTracker on AxMapContrlActiveView.ScreenDisplay ?

Discussion created by on Jan 16, 2013
First of all maybe this isn't the correct forum (bur could'nt find any better). We are developing a C# winform application using ArcGis Engine 10.1 SP 1's AxMapControl.

Shortly we have a reantrancy problem. Then we have spend hundreds of engineering hours finding out why. What we have observed is that while the axMapControl is processing a WM_PAINT it also processes other messages. We have digged into the code (Esri dll's) and found out that esri setup a CancelTracker while painting. On the CancelTracker a method CancelTracker::continue() is called, which then calls a method CancelTracker::update(). This method does Win32 API calls to PeekMessage and DispatchMessage, i.e. performs a MessageLoop. This obviously implies that our application is invoked with for instance WM_TIMER messages and user clicks while painting. We perform modifications on the AxMapControl's GraphicsContainer (from which WM_PAINT in this case is drawing) in the timer and click handlers for these messages, and then we observe a crash. Our Hypothesis is that the graphicscontainer is being itereated through (ArcGis code) while the control is painting (processing WM_PAINT), then the click handler is fired deleting an element (our code) via a call to the graphicscontainer's deleteElement(...) which then makes the draw iterator invalid (which is not in our hands) -> crash when painting continues.

So as a workaround we want to disable the CancelTracker. Unfortunately the property AxMapControl.ActiveView.ScreenDisplay.Canceltracker is null. But when our code is reentered through the above described "messagepump" it is not null, but then it is too late to disable it. We hope we can call something setting AxMapControl.ActiveView.ScreenDisplay.Canceltracker.CancelOnClick and AxMapControl.ActiveView.ScreenDisplay.Canceltracker.CancelOnKeyPress to false which then hopefully lead to the CancelTracker not doing MessagePumping! Any better suggestion avoiding the message pumping is welcomed.

We are 99.9% sure that we are not doing anything wrong (we spend many hours using experienced (10 years+) developers).

/Thomas Fabricius
M.Sc.EE., Ph.D.
Principal R&D Engineer