Saving (Inter)face, Build Engine apps with a Software Factory?
I’ve recently been reading “Framework Design Guidelines”. It has a lot of good suggestions. But the suggestions on “Choosing between Class and Interface” seem to go against a lot of what I’ve become accustomed to with ArcObjects.
Specifically, on page 80, they make a pretty good case for why you’re usually better off using abstract classes instead of interfaces for “separating contract from implementation”.
In addition to ArcObjects, this also seems contrary to what Juval Lowy also promotes in his book, Programming .NET Components.
While I’ve grown comfortable with interface-centric design, I wonder how much easier life would be if the ease of use offered by ArcObjects’ BaseCommand and BaseTool were introduced to other areas, such as dockablewindows and toolcontrols.
I wish I had more time to look into Software Factories. Seems like I’ve written the same basic application with ArcEngine so many times I could probably do it in my sleep. I wonder if it would be possible to use VSTS to build a factory, then just tweak the factory to crank out a new ArcEngine based application for a different problem domain. Speaking of domains, I wonder what a “domain specific language” for ArcObjects would look like. Seems like there should be a word for a mapcontrol buddied with a tocControl and a toolbarcontrol.
Helpful random arcobjects Tip:
Zombie toolbar names showing up in Arcmap under View>Toolbars?
I went into my registry and deleted everything but the default entry under HKEY_CURRENT_USER\Software\ESRI\ArcMap\Settings\CommandBarNameCache and this solved the problem.
Arcmap apparently rebuilds this cache,sans zombie, next time you view the menu.
Would be nice if MxCommandBars.Unregister would clean this up.
Kirk
8 comments so far
Leave a reply
Nice to see you blogging Kirk, I look forward to some insightful articles on ArcObjects.
cheers
brian
Thanks for the command bar tip! Pesky thing wouldn’t go away, but your tip fixed it.
I noticed that you are developing on C#. Which advantages you could straight point out using .NET technollogy over COM when related to ArcObjects?
Hi Milver -
Personally I find the main benefit to be VS.NET, which is so much more pleasant than VB. I don’t know if it is a bug in my configuration, but with VB6 I often get a “permission denied” error when compiling a dll with binary compatiblity (as if the dll cannot be overwritten due to some other program using it, even though I’m sure this is not the case). So I have to close & re-open the project, which is a pain. Breakpoints are not saved with the project in VB6 as they are with VS.NET. VB6 has no way to assign guids in your code for typelibs, clsids, etc. as you can with VS.NET, so there’s no need to keep an old dll around for binary compatibility.
VB6 IDE seems to be unstable when connected to anything other than Visual Source Safe.
Seems like a lot of the controls vendors are shifting away from supporting ActiveX controls and focusing all their resources on .NET, e.g. Infragistics and CommponentOne.
My thoughts are obviously slanted towards IDE ease of use comparisons, no doubt there are other factors to weigh, but these are the ones that come right to mind as I work on some legacy projects with VB6, then come back and use VS.NET.
Kirk
Very good reading. Peace until next time.
WaltDe
Regarding the dll problem and VB6 vs. VB.NET – I just started on a VB.NET project (a dll library building an extension to ArcMap in VS.2003 – .NET 1.1) using ArcObjects (manily Desktop staff) and am having a simillar problem with dlls so it does look like it is more then VB6. Having said that it happens fairly infequently.
Also, I think that recommanded way of removing of zombie toolbar names is by using the ArcGIS’s Compenent Category Manager (part of developer tools that come with ArcGIS 9.1).
Last but not the least – as a newby to ArcObjects development I very much thank you for your blog and looking forward to it prospering many years into future.
Hi Ismar. The thing about the zombie toolbars is that last time I looked into it, they would appear even though they were no longer registered in the ESRI Mx Commandbars component category. Apparently Arcmap uses the guid in the registry without first checking to see if the guid is still registered in the category. Maybe this has been fixed at 9.2, haven’t checked. Thanks for the positive feedback!
Kirk, you are great job.