I had picked up a book on Silverlight 2 some time ago, but actually found the easiest way to get started was with the tutorials at Silverlight.net. Tim Heuer’s series there is a great run-through of the main features in Silverlight. I then looked through some of the lessons in the Learn section, like Jesse Liberty’s videos. With those under my belt, I was able to get started with the ESRI API. I’ve also picked up Matthew MacDonald’s Pro Silverlight 3 in C#, which is a wonderful resource that goes into great depth (it’s not a tutorial format, so best to use it as a resource/reference).

I’ve mostly used Visual Studio 2008 for Silverlight so far. Expression Blend 3 is pretty much essential, though, if you want to do complex styles or animations. Since clients typically are attracted to Silverlight because of its fancy graphics and animation capabilities, that means Blend is a must, even for developers. Silverlight/XAML allow you to completely customize the look and feel (i.e., template) for standard controls like buttons and checkboxes. That sort of thing is painful and slow to do via markup in Visual Studio. Blend is also very useful for setting bindings for data sources (more on binding in a moment). I had heard that Visual Studio 2010 would allow design-view editing like Blend, but my experience so far with the release candidate isn’t promising. VS 2010 RC handled a very simple XAML page, but threw up its hands when I tried to view a more complex (and real-world) page. It also doesn’t seem to have Blend’s capabilities for editing properties, styles, and bindings. It also seems more sluggish than VS 2008.

Some day, I hope Microsoft creates an IDE that combines the capabilities of Blend and Visual Studio. Microsoft plays up transitioning between the two, but it’s fundamentally weird to have to switch back and forth between applications. You need Visual Studio for most any code writing, since Blend has no intellisense and can’t be used for debugging (no stopping at breakpoints, etc.).

One of the best aspects of Silverlight is the layout engine, or in other words, no more HTML/CSS hassles. I’ve torn many hairs out with ASP.NET applications in trying to get an element to go where I wanted it, or to look as I needed it to. Silverlight (actually XAML, the markup language it shares with WPF) allows you to place elements precisely, without the weird quirks of CSS or the vagaries of browser implementations. It took a while to get the hang of XAML layout and styles, like margins, padding, alignment and such, but once you understand the system, you can pretty easily lay out your page as you want. It’s also a snap to get the application to fill the page even when the user resizes the browser – something unnecessarily painful in traditional web pages.

Silverlight also makes it easy to consume Web services. You add a web/service reference in Visual Studio just like for a server-side ASP.NET application, and it builds the proxy for easy use in the application. I should mention though that I’ve had occasions where it fails to create the proxy properly, and I’ve had to generate the proxy manually and include it in the project. That works OK but then you have to refresh the proxy manually when you change the Web service. (I just noticed Ken Smith’s tip on deselecting the “Reuse types in referenced assemblies” option – seems to work on first try with a service that hadn’t worked previously.)

As a Web developer, I have to keep reminding myself that the Silverlight application is, for practical purposes, a desktop application. The action is happening on the user’s machine. No more worries about stateless Web requests—you can create an object and reference it later, without thinking too much about where to store it in the meantime. Of course there are hazards there too, like limitations on what you can access on the user’s computer (not much) and the possibility of creating a slow and memory-hogging application.

Another interesting difference from server-side Web applications is how resources like fonts work. Silverlight natively supports only a handful of fonts like Arial and Times New Roman. It doesn’t use fonts installed on the user’s computer. If you want to use a special font like Goudy Old Style or any ESRI symbol font, it has to be packaged into the .xap file the user downloads from the server. Not only does that quickly enlarge your download, but the end user can easily unzip the .xap file and pull out the fonts you embed (via the free.NET Reflector utility). That means that in most cases you have to get permission from the font owner to redistribute it, and typically pay a fee. I’m not sure what ESRI’s policy is on redistribution of their fonts.

Silverlight development does have some rough edges, such as:

• No ability to debug bindings. Binding to data and resources is at the core of Silverlight. You don’t typically create data control elements or set properties in code; instead, you bind properties and controls to data objects or other resources. That’s great when it works, but when it doesn’t, it fails silently. You might get a notice in the Output window, but you can’t step through the binding process. It’s often hard to tell if the data are bad, or your markup is faulty, or some other cause. I had a couple of occasions where the bindings actually worked, but I had inadvertently set the control to be invisible or zero width, so it didn’t appear! In ASP.NET you could at least view the source of the output page and see the markup produced, or use a tool like Fiddler2 to examine the page structure and elements. This data binding issue is a headache in Silverlight and leads to reduced productivity, as the developer has to do lots of round-about troubleshooting.
• No intellisense for XAML markup extensions. These markup extensions allow you to do things like bind the Text property of a TextBlock control to a field in a data source. But in Visual Studio there’s no help writing those statements (Blend does have a UI for some of this). You don’t find out you have errors until maybe at compile time, or even at runtime in some cases (or as mentioned above, the binding can simply fail silently).
• Unhelpful error messages, especially for markup issues. You’ll see messages like AG_E_PARSER_BAD_TYPE, with no information on which file/page contains the error, and sometimes no line information or stack trace. Hopefully you’ve just made a minor change to the markup so you have an idea where the problem lies, but that’s not always the case when this happens.
• Difficulty finding elements on the page. If you’re in the same context and know the name, you can reference the control, but if you’re, say, in an included user control, or the element was created programmatically without name, I haven’t found a way to search the entire application by control name or type. There’s the VisualTreeHelper, but that only goes up and down the immediate XAML tree, and doesn’t work everywhere (like in data templates).
• No automatic mouse wheel scroll in elements with scroll bars. If you add a ScrollViewer or have a ListBox with scroll bars, users can’t scroll content with the wheel, unless you pull in a third-party utility. Seems like a minor issue, but users have gotten very used to that convenience, so it should be built in. Silverlight 4 will expose a MouseWheel event, but you’ll have to handle it programmatically.

Ken Smith shared similar complaints in a couple of posts (here and here). Hopefully Microsoft will improve Silverlight regarding these behind-the-scenes issues over time, though Silverlight 4 doesn’t seem to offer too much improvement.

Despite these issues, I definitely enjoy working with Silverlight. It’s got a lot of advantages over traditional Web development, and plenty of power to create attractive and useful applications.

I’ll follow up with a post on the ESRI Silverlight API shortly.

Being part of a small development shop with 2 developers that is currently growing now with 25 developers, I have experienced frustrations along the way that I continue to learn from. I can’t tell you how many times that I spent the weekend busting my butt to get an application debugged and tied up tightly only to find that my boss can’t get it running the first time he tries it on his machine. My only response, as I think about the family events I missed over the weekend is… “I don’t understand what happened, it worked on my machine.”

Below are two short examples for creating a project. The first example roughly describes how I previously developed and release a project and the second example describes the procedure we use here at GISi today.

 Example 1:  A developer creates a project that is to be delivered to a customer. When the project has been completed, the installer for the application is built in release mode and the developer installs it on the development machine for testing.  After successfully testing the final product on the development machine, it is turned over to someone else for testing before it goes out to the customer.  (Well, let’s hope that is what happens anyway.)

Next, the developer turns the project over to the person that is going to install and test it on their computer.  After installing and testing the project, the tester goes back to the developer and says some portions of the application did not work or they got errors when clicking on a button or when opening or closing a dialog. Or, even worse, the installer failed to install the application. This is when the developer says, I don’t understand, I installed and tested it on my computer and… “It works on my machine!” But the reality is that it wouldn’t work on any other machine.

 Example 2:  A developer develops and debugs a project as the code is written for each button; tool; dialog; etc… to make sure everything is working as it should.  After the project has been completed and all of the bugs have been resolved, the installer for the application is built in release mode for testing.  Before the build is released for testing by others, the developer should test the release build to make sure everything was installed properly and the final product actually works as it did when testing in debug mode.  The developer can install on the development machine to make sure the installer works and has the correct information on the installer dialogs.  Also, the developer can test the product on the development machine to verify the product works as designed after it has been installed.  

However, before turning the project over for testing by others, the developer must install and test on a clean test machine.  One reason to test on a clean test machine is to make sure that all of the required assemblies; databases; registry entries and other required files get installed in the proper locations. Next, the developer should test the project on the clean machine to make sure all of the buttons; tools and dialogs work properly. If the developer follows this procedure before turning it over to someone for testing, he will be assured he won’t have to say well, “It works on my machine!”

There are several things to keep in mind when writing an extension method. First, the method must reside in a code module (choose Module from the Templates list when adding a new item to your project). Secondly, you must mark the method as an extension method using the Extension() attribute from the System.Runtime.CompilerServices namespace. Lastly, the first parameter of the method defines the class type you want to extend. Here is the code for our extension method:

    <System.Runtime.CompilerServices.Extension()> _
    Public Sub Zoom(ByVal map As IMap, ByVal envelope As IEnvelope)
        Dim activeView As IActiveView = DirectCast(map, IActiveView)
        activeView.Extent = envelope
        activeView.Refresh()
    End Sub

Notice the Extension() attribute has been added to the method definition and that the first parameter to our method is typed as IMap. This tells the compiler that it should bind this function to the IMap interface. When we call the Zoom() method this first parameter will not show up in the Intelli-sense and we will not have to pass in an IMap reference. Our Zoom() method will appear along with all of the other properties and methods on the IMap interface except it will be marked with the Extension tag. Here’s some code that calls our new method:

        Dim mxDocument As IMxDocument = DirectCast(m_application.Document, IMxDocument)
        Dim map As IMap = mxDocument.FocusMap

        Dim activeView As IActiveView = DirectCast(map, IActiveView)
        Dim envelope As IEnvelope = activeView.Extent
        envelope.Expand(0.75, 0.75, True)
        map.Zoom(envelope)

If you’re like me you’re now wondering how this is any better than how you’ve been doing it. I’m not going to try and list all of the pros and cons of using extension methods but I will point out what I think is one major advantage.  Extension methods show up in the Intelli-sense for the classes they extend.  I think this is very important because many times I write a method because I can’t find the method I need on the classes I’m working with.  I’m more likely to find and use an extension method than find a similar method on a helper class that’s located somewhere else.  If you put these methods in a common code library and all of the developers in your organization know to use this library then they should be more likely to see the methods as well.  This should help prevent multiple developers from writing the same functions.

There is still quite a bit more to know about extension methods that I can’t cover here so I’ll just refer you to MSDN with the link below. There is also a sample project you can download that contains the method we just created along with a couple of others.

http://msdn.microsoft.com/en-us/library/bb384936.aspx

Hopefully this article will get you thinking about some of the interesting things you can do to extend the ArcObjects classes but don’t stop there. You can use extension methods to extend any class. So if you’ve ever wished the String class had a few more methods or the Combobox control did something more just write your own methods and add them!

Ruth has a Bachelor’s Degree in Geography from Calvin College and has 8 years of data processing, QC and analysis experience.  She will be working at the IGI&S Support Center as a Senior Geospatial Analyst.

James holds a Bachelor’s Degree in Geography from University of Mary Washington and previously worked with the U.S. Department of State.  He joined the IGI&S Support Center team as a GIS Analyst.

Andrew will be joining the GISi team as GIS Technician upon receipt of his Bachelor’s Degree in Geography from Virginia Tech in December.   

Eric has a Master’s Degree in GIS and Public Administration from Salisbury University and has supported a variety of planning projects for the City of Cambridge, MD.  He will be rounding out the IGI&S Support Center team as a GIS Technician.

Adam recently graduated from the University of North Carolina Wilmington with a double Bachelor’s degree in Geography and History.  He will be working on site at Aberdeen Proving Ground (APG), MD as a Help Desk Specialist.

Christopher Fricke has a Bachelor’s degree in Geography and Environmental Planning from the University of Maryland and he has experience modeling smart growth initiatives in GIS.  He will be working as a Help Desk Specialist on site at APG, MD.

Aaron holds a Master’s Degree in Geography from Georgia State University and has been developing GIS applications for the last 7 years, with strong experience in C#, .Net and AGS.  He will be working out of his home office in Atlanta, GA as a Senior Developer on the RSIMS team.

Elena recently received her Master’s Degree in Biology from Virginia Commonwealth University and has held a variety of teaching and research assistantships.  She will be working on site at NAVSTA Norfolk, VA as a Senior GIS Analyst.

Casey has a Bachelor’s of Science from Eastern Michigan University.  He has experience in SDE SQL Server installation and administration, map service configuration, AutoCAD integration, development of custom VB tools and Model Builder.  He will be working on site at Oakland County, MI as Senior GIS Analyst.

Steve has joined the company as a Solutions Architect.  He has a long list of GIS credentials, most notably, leading ESRI Technical Sales and supporting Marketing in the Southeast Region since 1998.  He has an advanced knowledge of Enterprise design and implementation of AGS, with experience in the .NET ADFs, and each of the AGS API’s.  He will be working out of his home office in Atlanta, where he will be supporting both the North and South Business Units in a TA role, supporting the Sales team as a technical marketing guru on several initiatives, and supporting corporate R&D efforts.

One of the most common questions I receive from clients lately is: “Which API should I use?”  Unfortunately it is not a simple answer; ESRI provides three APIs and two ADFs which include; JavaScript API, Flex API, Silverlight API and the .Net and Java Web.ADFs.  I answer the question with a combination of questions needed to isolate the answer.  For example:

What version of ArcGIS server are you running?

• The ArcGIS APIs are only supported at the 9.3 version.  Any version bellow ArcGIS Server 9.3 would require the Web.ADF.

Is browser plug-ins an option?

• ArcGIS Server APIs for Flex and Silverlight require browser plug-ins. If your application cannot require a plug-in, the JavaScript API or one of the Web. ADFs will need to be your choice. 
• The ArcGIS Server API for Flex requires the Flash plug-in, which 99% of Internet clients seem to have. The Silverlight plug-in has not yet reached the same level of ubiquity, but can be expected to gain ground.  Plug-ins come in different versions, which may also present a hurdle in getting end users to experience the Web site in the way you expect. If you choose to use Flex or Silverlight, it is wise to consider how flexible you are to upgrade plug-in versions. The ArcGIS API for Flex requires Flash Player 9 or above. The 1.0 release of the ArcGIS API for Silverlight requires Silverlight 2 or above.

How quick do you want to get it done?

• Web.ADF out-of-the-box is the fastest way to deploy, followed by Flex, JavaScript, and then Silverlight.  To get a client jumpstarted they have the following options;  the sample Flex viewer template can be downloaded and configured using an xml file.  JavaScript can be added to an html page and edited using note pad.  Silverlight requires Visual Studio and Expression Blend and the sample template has some quality issues.

Which platform are your developers most comfortable with?

• Many beginning developers find the JavaScript and Flex easier to learn than the Web.ADF or Silverlight, but Silverlight and ADF have the power of the .NET framework behind it.  I suggest choosing a platform that your staff already knows and can save you ramp-up costs.  However, we are seeing a lot of community based support for the Flex API, lots of contributed samples and code snippets. We expect to see the same sort of community support for the Silverlight API as well. Additionally, the .NET ADF can become fairly heavy if a lot of customized functionality is needed. This can impact performance.

What Integrated Development Environment (IDE) is needed?

• When you choose an API, you are also making choices about the environment where you’ll spend your time coding. Flex developers use Adobe Flex Builder 3.  .Net and Silverlight developers use Visual Studio or Visual Web Developer Express. Expression Blend is another option for Silverlight developers. Java developers use Eclipse or NetBeans. JavaScript programmers probably have the most choices, including the option to just write code in a text editor.  Cost of the IDE may also a factor.

Do you need to edit features over the Web?

• GISi already has a limited editing framework for the APIs.  The .Net and Java ADFs offer access to fine-grained ArcObjects, which can be used to edit feature geometries. The ADFs contain out-of-the-box tasks for basic Web editing operations. If you need to build an application with Web editing fast and now, go with the ADF.  More editing features are planned for the JavaScript, Flex, and Silverlight APIs at the release of ArcGIS Server 9.4 in 2010.

What is the industry trend?

• I’m definitely seeing a trend away from the ADFs and towards the APIs.  Out of the APSs it’s a close race.  Flex has come out of the gates fast and has a bit of a lead on the others, but Silverlight has Microsoft behind it and ESRI is definitely working close to Microsoft.

After answering questions like these, the clients usually have a clear answer.  Several of my answers might be subjective, so I try to keep my personal perspective or opinion and desires out of the equation, unless asked directly.

Another benefit is centralization. If you’ve been following my previous articles you’ve probably noticed there are several classes that have been included in each of the sample projects. By including these classes, we’ve eliminated the need to keep writing that code each time we want to use it. However, what if we found a bug in that code? As it stands now, we would have to fix the bug in each project that contains the class. If we had instead put those classes into a common code library we would only have to fix the bug in one place, saving us a lot of time while ensuring that the same fix is applied in each project. The same would be true if we decided to extend one of those classes to add new functionality.

Creating your own code libraries is relatively easy to do. The most important thing is to give it some thought before you get started and design a system that will work best for you. I’ll spend the rest of this article going over some of the things we here at GISi came up with when implementing the code libraries that we use for our projects. There is also a sample project that you can download that demonstrates some of these ideas.

Before getting started, there are a few things to think about. First and foremost is what your library (or libraries) will be used for. Here at GISi, we develop both web and desktop solutions so we created 3 separate libraries. One library is for web development, one is for desktop (Windows) development, and the other is a common library that can be used for both. This makes sense for two reasons. First, web development and desktop development are very different from each other so it really makes sense from a logical standpoint to separate the two. The second is a technical reason. The web classes will most likely reference the ESRI web assemblies and the desktop classes will most likely reference the ESRI desktop assemblies. If we didn’t separate the two, then our library would require both ArcGIS Server and ArcGIS Desktop to be installed on the client machines. This is certainly not feasible so we really had no choice but to create two libraries. We then created a third common library that doesn’t reference any ESRI assemblies and contains classes that are compatible in both environments.

The first step is creating the code project. Open Visual Studio and create a new project, choosing Class Library as the project type. Choose the name of this project carefully as it will be with you for a long time and changing the name after you’ve deployed it a few times could be troublesome. After you’ve created the project, it’s time to start adding your classes.

We use namespaces to organize the classes in our libraries. This is how the .NET Framework is structured so we thought it would be good for consistency to do the same. It is a good idea from a technical standpoint because it allows us to create globally unique types which are important when it comes to deploying the library. It seemed only natural for our root namespace to be GISi. You can set the root namespace for each of your code libraries on the Application tab of the Project Properties page.

It is common practice to organize the class files in your project by using folders that mimic the namespaces defined by your class model. Since we created 3 libraries, we created a namespace for each library. We created GISi.Web, GISi.Windows, and GISi.Common. This way we can tell which code library our classes belong to without having to look them up. Each of our code libraries contains an appropriate root folder.

You may decide that you need to further organize your classes within your code library. For our Windows library we needed several levels of organization to keep things from feeling cluttered. For example, all classes dealing with user interfaces go into GISi.Windows.UI and all classes dealing with ArcObjects go into GISi.Windows.ArcObjects. Since we have many classes dealing with ArcObjects we further organize them according the to ArcObjects library they primarily use. So, our code library contains classes in GISi.Windows.ArcObjects.Carto, GISi.Windows.ArcObjects.Display, and several others. You are certainly not required to do it the same way but I just wanted to mention it so that you’d be aware of it and could use this information when planning your own libraries.

So let’s take a look at the sample project and see some examples of what I’ve just been talking about. If you look at the Application tab in the Project Properties you’ll see that the Root Namespace has been set to CodeLibrary. This will be the root for all of the classes in the library. You’ll also see that there have been several folders added to the solution. These folders mimic the namespaces used by the classes they contain. For example, if you look at the code module for the TabProcessorDialog you will see the namespace has been declared as Windows.UI and if you look at the MapHelper class you will see its namespace has been declared as Windows.ArcObjects.Carto. This is very important and is something you will need to do for all of the classes that you add to your library if you want your classes to be organized into namespaces. Note that the namespaces defined in the classes do not include the CodeLibrary root. This is because the root namespace you defined at the project level will be applied to all of the classes when the project is compiled.

I think it’s also important to mention that all of the classes contained within a namespace do not have to be in the same code project or solution. Each of our code libraries has its own code project contained within its own solution yet all of them use GISi as their root namespace. As long as you define the namespace in your class code it does not matter where that class is located.

The sample project is pretty simple but should be enough to get you started. The classes it contains are simplified versions of the same classes that we use in our own projects. In future articles I’ll go over how we use these code libraries in our projects and how we handle deploying them. Future sample projects will also contain this code library and I’ll probably be adding a class or two as we go along. 

Zac Odom has a Master’s Degree in Geography and more than 10 years experience in developing web, database, and geospatial applications and comes to us after leading the efforts for Headquarters United States Air Force’s (USAFE) GeoBase implementation at Ramstein AFB in Germany.  He will be working as an Architect in the Birmingham office.

Matt Sheehan holds a Master’s Degree in Geographic Information Systems and has been an internet map developer for 10 years using a variety of applications, with special expertise in Flex.  He will be working remotely out of his home office in Utah as a Senior Developer.

Nadav Epstein has a Bachelor’s degree in Physical Geography and has four years experience in data collection and analysis.  He will be working at the IGI&S Support Center in the D.C. office as a Geospatial Technician.

Our first instinct might be to use the method I discussed last time and create an Update method on the list dialog that would refresh the list. This method could be called by the Create Widget command each time a new widget is created. While this solution would certainly work, it’s not really the most elegant solution. As our application grows, we may add more ways to create widgets or add more dialogs that list widgets. If this happens, it would mean we would have to go back and modify our current Create Widget command to update all of the new dialogs that list widgets. It would also mean that we would have to remember to call the Update method on our current List Dialog each time we implement a new way of creating a widget. As you might imagine, it won’t be long before we will be spending hours writing code that ensures all of our components are communicating with each other properly. This is something we’d like to avoid if at all possible.

A better solution would be to create a custom event that is fired each time a widget is created. Our Create Widget command would fire this event when the widget is created and the Widget List dialog would subscribe to this event and update every time it fires. In the future, any new methods of creating a widget that we add would simply fire this same event and any dialogs that need to list the widgets would simply subscribe to this event. We wouldn’t have to go back and modify any of our existing components. Using this solution, we can create an application that is easily scalable with minimal effort.

The sample project that accompanies this article demonstrates the scenario I’ve just described. Upon opening the project you’ll see we have a class named Widget that defines what a widget is. For demo purposes, it will simply be an object with a name. The WidgetEvents class defines what events will be available. For the time being, we’ll just define events for creation and deletion. The WidgetCreated event will receive a reference to the widget being created through its event arguments. The WidgetDeleted event will receive the name of the widget being deleted. Note how these arguments are defined via custom event argument classes. This is the key to passing information through events. You can create custom argument classes that allow you to pass whatever information you want. Also note that the WidgetEvents class has a method that fires each of the events. The components within the application will call these methods whenever they need to fire an event.

Our application will need a central instance of the WidgetEvents class that can be accessed by the individual components. Extensions are an easy way to provide this type of thing. The WidgetExtension class implements IExtension and provides a reference to the WidgetEvents class.

The project also contains two command classes that show two dialogs. The Widget dialog creates new widgets. See the code behind the Create button to see how it creates the new widget, assigns it to a new instance of the event arguments class, gets a reference to the extension, and calls the method on the WidgetEvents class to fire the WidgetCreated event. The Widget Manager dialog lists the widgets that have been created. Note how it declares the event listener WithEvents and sets the reference in the form’s Load event. Note also how the WidgetCreated event handler has been implemented. When you compile and run the application, you should be able to show both dialogs by adding the commands to a toolbar and clicking them. Type in a new name on the Widget dialog and click Create. You should see the Widget Manager dialog update almost immediately with the name of the new widget.

This sample provides the bare bones of how to communicate with events. As mentioned earlier, the WidgetDeleted event has been declared but, as you may have noticed, isn’t implemented in the sample. As an exercise, you might want to take a shot at implementing it. If you aren’t familiar with creating and using your own custom events then I think you’ll find them to be a powerful tool that you may want to start using.

The sample project that accompanies this article contains a sample dialog with two buttons. The first demonstrates how to pass information from a form to a custom ArcMap command. The second shows how to pass information from a custom ArcMap tool to a form.

Looking at the code behind the first button, you’ll see that we are calling a custom command that performs a fixed zoom in operation. This custom command is similar to the built-in Fixed Zoom In command found in ArcMap. The difference is that our custom command allows the zoom factor to be specified, thus changing how much the map is zoomed. Looking at the implementation of the custom command you’ll see that it has a property named ZoomFactor. The trick to gaining access to this property is shown in the form code. The code gets a reference to the command by calling ICommandBars::Find(). We can get a reference to the underlying ICommand object from ICommandItem::Command. Because this reference is typed as ICommand we need to cast to the actual class type of our command class. Once we’ve done this we have access to the ZoomFactor property. We can then set the property and call Execute() to run the command.

An alternative method of doing this would be to create a custom interface that defines the ZoomFactor property and have our command class implement this interface in addition to implementing ICommand. This would certainly keep more to the COM model than simply defining the property directly on the class but it isn’t really necessary. If you have a set of properties and methods that you want to be common across multiple command and tool classes, then you might want to consider using a custom interface to ensure consistency. Otherwise you may find it simpler to do it as shown.

The second example demonstrates how to pass information from a tool to a form. Looking at the code behind the button you’ll see that it is calling a custom select features tool similar to the one shown in my last article. The difference here is that this tool will update the calling form to display the number of selected features. In order to do this, the tool class will need a reference to the form. Looking at the tool class you’ll see that a property has been added to allow the form reference to be set. This property is set in the form code the same way as in the previous example. Looking at the form class you’ll see a method has been added that will update the label text on the form using the value passed in as a parameter. The code in the custom tool calls this method after the features have been selected and passes in the selection count.

The real trick here is getting a reference to the form. In this particular example it’s easy because the tool is being called from the form in question. All we have to do is pass that instance of the form. A more common scenario requires updating a form displayed by another command or tool class. In this case you will need to add a property to that command or tool that will return an instance of the form it displays. The code in the tool class that needs to update that form will first need to get a reference to the command or tool that displays the form. This is done by calling ICommandBars::Find() just like we did in these two examples. Once you have that command or tool reference you can get the form reference from the property you added and pass it to your custom tool.

As with anything else in the programming world there are other solutions than these but I think the two we have demonstrated here are relatively simple and easy to understand. Hopefully this will get you thinking about how individual components can work together within your applications.

Michael holds a Master of Urban and Regional Planning degree and has more than 20 years experience developing GIS software.  He is working with the Federal Projects team as a Senior GIS Developer out of his home office in Arizona.

Denise has a Master’s Degree in Geography and 8 years of GIS expertise in data compilation and QC.  She is working onsite as a Senior Analyst supporting the Army at ATSC in Fort Eustis, VA.

John has provided GIS expertise to many organizations for more than 10 years, including system and database management and developing solutions using .NET for Desktop and Web applications. He has joined the Federal Projects team as a GIS Developer and will be working out of his home office in Tennessee.

Rick holds a Bachelor’s degree in Engineering Business Management and brings GISi more than 10 years of contract administration expertise in both DoD and commercial programs.  He is working in the Birmingham office as a Contracts Administrator for all of the company’s business units.

Beth has a Bachelor’s degree in Geographic and has more than 5 years experience supporting a variety of GIS initiatives, primarily focusing on data development, QC, and training.  She is supporting the Navy Team as a Senior Analyst onsite at NAS Jacksonville, FL.