As a part of writing any unit-test to test the add-ins (buttons/tools/extensions) and their behavior in ArcMap, it is essential to automate starting ArcMap and running the commands. Here is a good article on how to automate ArcMap.
With the release of Vs 2008 around the corner, this is a good site to know what is new in the product
We always end up in a situation where we need to update a value directly in the recordset and set it to null. E,g. when we are dealing with DateTime fields and wish to set the field to null. If you just leave the field blank and try navigating to the next row, SQL Server throws an error.
To explicitly set a value to null, click on the field in the resultset and type CTRL-0 (zero). This sets the field to null.
In SQL Server 2005 Management Studio, do not forget to click on Execute button to save the edits.
A common scenario that ArcObjects developers come across is creating a button or tool in ArcMap whose image changes when clicked.
Example: Say you wish to create a “LogOn” button whose bitmap needs to change to “LogOff” bitmap once the user has logged in.
Just setting base.m_bitmap to the new bitmap does not update the bitmap in ArcMap. Instead you need to use the BaseCommand.UpdateBitmap method.
Per ESRI .Net documentation:
UpdateBitmap changes the Bitmap for the command. Call this method to update the icon used for the command at runtime, after the command has already been instantiated.
When working with bulk editing or editing operations that might cause performance hits, try using IWorkspaceFactorySchemaCache and enable schema caching. This is supposed to improve the performance. Some people have reported improved performance (3 times) on even DifferenceCursors when enabling schema cache.
In our applications, we use Access based Personal GDB files to cache data in order to limit network read/writes and also improve performance by doing processing locally. The best thing with Access was ability to use Jet OleDB provider and ADO.Net to read/write and do complex math on our data. That way we are not limited to use relatively slower and limited functionality ArcObjects. However, the problem with Access is the delay in flushing data. We would insert some data to a table and sometimes this data would not be flushed to the mdb file, hence immediate reading of the table would not return the just inserted records.
As we are investigating other options, I liked the idea of file based gdb in ArcGIS 9.2. However, the limitation is inability to use ADO.Net Oledb provider to access data. ESRI Oledb provider can be used for reads (no inserts and deletes), but there is no documentation if it supports file based gdb. My wishlist for ArcGIS 10.0 would be for ESRI to extend the ADO.Net Oledb provider and give native access to ESRI geodatabase data.
This is an excellent white paper on .Net coding guidelines. I couldn’t have written it better. A must read.