MSDN Magazine - July 2008 - (Page 22)

Writing the Add-In Once the pipeline is in place, I can write add-ins against the addin view. Writing the add-in is as simple as possible. All an add-in developer needs to do is to create a class that inherits from the addin view, and mark the add-in implementation with the AddIn attribute. The rest of the code can be written almost as if there were no pipeline between the host and the add-in. There are a couple of caveats, however. One is the object identity issue I discussed earlier, and the second is performance, depending on what isolation boundary is used. For performance benchmarks, see go.microsoft.com/ fwlink/?LinkId=117527. Currently, add-ins cannot directly display Windows Forms controls on the host application’s forms. However, they can use any of the following three methods: they can display their own forms (note that if the add-in is running in some partial trust scenarios— like the Internet trust level—the user will see a security warning on the add-in form when it is loaded); they can display Windows Presentation Foundation (WPF) controls directly on the host application’s forms (please see go.microsoft.com/fwlink/?LinkId=117528); and they can use Windows Forms controls that are wrapped in WPF containers (see go.microsoft.com/fwlink/?LinkId=117529). Windows Forms have some threading requirements that must be met. For example, an add-in extending a command-line application must create a new thread to construct a form and process its events. This is because command-line applications use the multithreaded apartment (MTA) model by default, and Windows Forms require the single-threaded apartment (STA) model for UI threads. The solution is simple: add-ins extending a Windows Forms application can just include two lines to display forms (given the add-in is activated and used from the host’s UI thread), like so: AddInForm form = new AddInForm(); form.Show(); Figure 9 Path Taken by an Event through the Collaboration Add-In Figure 10 Three Instances of the ShapeApp Connected Together Using the exposed interface, one can create really powerful addins. One example is the collaboration add-in included with this sample. It allows two users of the ShapeApp using two different machines to edit a drawing together in real time. The collaboration add-ins connect to each other through Windows Communication Foundation (WCF), allowing this interaction to work globally over the Internet. A screenshot of the connect screen can be seen in Figure 8. Once two add-ins are connected to each other, any new documents created or opened on either end are shared; that is, changes on one machine are sent in real time to the other. This is accomplished using events. When the collaboration add-in is loaded, it subscribes to all the application’s events. When a new drawing is created, the CreatedDrawing event is fired. The add-in receives this event and subscribes to all events for the new drawing. Similarly, it subscribes to all shape-related events when shapes are created. This allows the add-in to track all user actions and propagate them over to its peer. Figure 9 shows the path taken by an event through the collaboration add-in. On Machine 1, the user performs an action (such 22 msdn magazine The Collaboration Add-In as changing the position of a shape). This makes the host fire an event, and the collaboration add-in receives it. The collaboration add-in creates a message and sends it through WCF to the add-in on Machine 2. This add-in then performs the same action on the host. Note that it temporarily unhooks event handlers when performing actions on the host. This prevents the event from coming back to the add-in, which would result in an infinite cycle. More interesting scenarios are made possible by using WCF. Since the collaboration add-in hosts a service, any number of clients can connect to it. This allows more than two people to work on a drawing together, seamlessly. Figure 10 shows the connections among three machines. The collaboration add-in on each machine is connected to all the others. Wrap-Up Now you’ve seen how the ShapeApp is adapted to host addins using the .NET add-in framework. You should have a good idea of the capabilities of the add-in framework and how it can be used to create an add-in that seamlessly turns the ShapeApp into a real-time collaborative editor. Please feel free to leave feedback or ask questions on the Add-In Team Blog at go.microsoft.com/ fwlink/?LinkId=117530.  Mueez Siddiqui is a Software Development Engineer in the CLR security and extensibility team at Microsoft. CLR Inside Out http://go.microsoft.com/fwlink/?LinkId=117527 http://go.microsoft.com/fwlink/?LinkId=117527 http://go.microsoft.com/fwlink/?LinkId=117528 http://go.microsoft.com/fwlink/?LinkId=117529 http://go.microsoft.com/fwlink/?LinkId=117530 http://go.microsoft.com/fwlink/?LinkId=117530

Table of Contents Feed for the Digital Edition of MSDN Magazine - July 2008

MSDN Magazine - July 2008 Contents Toolbox CLR Inside Out Flex Your Data Data Points Advanced Basics Office Space Cutting Edge Data Services ADO.NET Data and WPF Transactions WCF P2P Test Run Security Briefs Foundations .NET Matters {End Bracket}

MSDN Magazine - July 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.