IDocumentEvents that take a return value do not seem to work properly in ArcMap 10.1.

[IanMcCrorie]

Hi,

I have custom extension code which listens for a variety of events, including IDocumentEvents . While all events fire correctly, those expecting a return value do not seem to handle the return values correctly.

In order to try and prove the issue I decided to write a simple Add-in to test this. So having used the templates in VS2010 C# and .Net 4, I have created a simple Extension Add-in for ArcMap 10.1, essentially writing very little code but simply commenting in the default 'WireDocumentEvents' code which listens for and responds to BeforeCloseDocument. BeforeCloseDocument should abort the closing of ArcMap when TRUE is returned, however having displayed and responded to the message dialog the document behaves the same and closes whether TRUE or FALSE is returned. This confirms the behaviour from my custom extension code.

I have also found similar behaviour with ArcMap ignoring the return value with the OnContextMenu event and I think now I can also attribute some previous issues I have had with IEditEvents similarly.

Is anyone aware if this is a documented error with ArcMap 10.1 or indeed does anyone have these events working? They do work in VBA but the signatures are different and VBA is not a viable coding alternative for me, it was used simply as a test.

Appreciate any feedback.

[DuncanHornby · Accepted solution]

Ian,

One alarm bell that went off is that you specifically mentioned you are developing for version 10.1 but you are using .Net 4.  As I understand it, each version of ArcMap is developed around a specific version of .Net and in the case of 10.1 I believe it was .Net 3.5. On GIS SE someone asks a similar question here​. I would suggest you rebuild your code against .Net 3.5 and give that a go?

Duncan

[IanMcCrorie]

Duncan, thanks for the reply.

I changed the target framework to 3.5 as you suggested and it did indeed solve the problem for the test add-in extension. The BeforeCloseDocument does now leave ArcMap open when TRUE is returned. This is a good and bad result. Good, it answers the question. Bad, a huge issue with ArcGIS 10.1, a large amount of code to rebuild and re-test against .Net 3.5 (in fact unlikely the client will authorise resource for that) and what are the chances of ESRI fixing this at 10.1?

The ESRI documentation clearly states that 10.1 code can target .Net 4 http://resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/index.html#//000100000p7w000000

I chose .Net 4 over 3.5 when I upgraded the codebase from 9.1 a year or two ago, in order to 'future proof' as best I could!

I will report this as a bug to ESRI and continue to code around all these events as best I can.

Thanks again for the reply.

Ian

[DuncanHornby]

Ian,

Glad I was able to help. Unless you have specifically used something that is only in .Net 4 (e.g. an Interface or some new object) then (I am going to be rash here) I don't see why it should matter (I'm now waiting for a hail of bullets from .Net gurus...). A few years ago I did something similar, .Net 4 must be better than .Net 3.5, developed some code, it would not work, changed it to .Net 3.5 and as I had used nothing specific to .Net 4 my code compiled and worked without error.

As for bug fixes in 10.1 forget about it, ESRI march on with newer and greater stuff leaving their older software to die a slow death. I personally will miss VBA when they finally pull the plug.

Duncan

[IanMcCrorie]

Duncan,

85 thousand lines of code across 4 desktop applications......to tell you the truth I am not sure if there are any .Net 4 issues or not. I guess I might just need to try it and see at some point.

The issue now is that the code has all been live for over a year and while there are still some minor irritants (such as a small grey box appearing on a handled Context Menu) the fact I did not know there was a problem with Events in general means most had to be coded around during the 10.1 upgrade. Things like preventing the cross in top corner shutting down ArcMap were relatively easy fixes using WinAPI code but preventing ArcMap sending bad geometry to ArcSDE via BeforeStopOperation was a major re-write. All the geometry checking had to be moved to the OnSketchModified, to warn the used not to complete the sketch, as I was unable to fix and replace the geometry in BeforeStopOperation as the ArcObjects documentation indicates you should (I haven't proven this one is definitely the same reason yet...but I suspect it is).

I have logged the call with ESRI(UK) support but as you say I won't be holding my breath!!

Thanks again.

Ian

**An update - ESRI(UK) tell me I have no SDK or API support - I wasn't aware they had separated support but that's not my job....anyway they also included the following related bugs NIM082533 and NIM082940 - both reported 2012 and apparently nothing done. These are bugs for individual event issues and there seems to have been no acceptance that events in general do not return values with .Net 4.0. This issue is a lot bigger than one event not responding correctly. Nothing will be done, code around as usual!!