What Does It Do?

The feeder change event gives before and after states for network state changes on any differences resulting from a user edit session. Listening and reacting to these changes allows your customizations to provide instant feedback to users. At a high level, your customizations will:

1. Keep track of all feature changes that involve feeder information in an edit session
2. Check for changes when the user posts (when the Feeder Synch tool is turned on)
3. Notify integrations of any differences

Keep in mind that the performance advantage of Feeder Manager (FM) 2.0 is that it minimizes database-write operations.. You should not use events to update your database too often, or you will negate the speed advantages of FM 2.0. For example, using the events to update the label text field on conductors could be costly because of the large number of features that might need updating.

Any custom assemblies you develop will need to reside in a subfolder of your Miner and Miner directory named FeederManager (one word, Pascal case). The default location would be \Program Files (x86)\Miner and Miner\FeederManager. You do not need to register your assembly with RegX.exe.

using System.ComponentModel.Composition;
using System.Linq;
using System.Windows.Forms;
using Miner.Geodatabase;
using Miner.Geodatabase.Edit;
using Miner.Geodatabase.FeederManager;
namespace MultifeedWarning
{
    [Export(typeof(IEventHandler<FeederChangedEvent>))]
    public class Fm2MultifeedWarning : IEventHandler<FeederChangedEvent>, IEventSignup<IConnectionProperties>
    {
        /// <summary>
        /// Called by the Feeder Manager 2.0 workspace extension when an edit session is started.  Return true
        /// to receive events for the workspace identified by the given connection properties.
        /// </summary>
        /// <param name="src">The source.</param>
        /// <returns></returns>
        public bool SignUpForEvents(IConnectionProperties workspaceBeingEdited)
        {
            // Return true to receive events for all workspaces.
            return true;
        }
        /// <summary>
        /// Handle events is called for each edit which modifies feeder information.
        /// </summary>
        /// <param name="e">The event arguments.</param>
        public void HandleEvent(FeederChangedEvent e)
        {
            // Check for events where the multifed attribute of a feature changed from true to false.
            var modifiedFeatureEvents =
                e.Diffs.Where(diff => diff.InfoAfter.IsMultifed == true && diff.InfoBefore.IsMultifed == false);
            if (modifiedFeatureEvents.Any())
            {
                var warning = string.Format("{0} features will be multifed as a result of the previous edit.  Do you wish to continue?", modifiedFeatureEvents.Count());
                DialogResult result = MessageBox.Show(warning, "Warning", MessageBoxButtons.YesNo);
                if (result == DialogResult.No)
                {
                    Editor.AbortOperation();
                }
            }
        }
    }
}

Implementing Feeder Change Events

Basic implementation is a three-step process:

1. Define a class that implements both the IEventHandler<FeederChangedEvent> and IEventSignup<IConnectionProperties> interfaces. Class must also be identified using the Microsoft Extensibility Framework Export attribute.   

2. Implement the IEventSignup interface. FM 2.0 calls the SignUpForEvents method when editing begins on a workspace. The purpose of this interface is to inform your customization that a workspace is ready to fire events. IEventSignup is called once per edit session and must return true to receive events for the given workspace (identified by the IConnectionProperties arguments), also useful for initialization of objects used within the scope of an edit session.

3. After IEventSignup, you will need to implement IEventHandler<FeederChangedEvent>. The FeederChangedEvent.Diffs property will have differences for each feature that has feeder information that has changed. The FeederWorkspace property will identify the workspace that is firing events. If you need additional feeder information, you may want to create a FeederInfoProvider from the FeederChangedEvent.FeederWorkspace property. Events are fired within an edit operation and the handler has the opportunity to cancel the operation by calling Editor.AbortOperation.

Special Cases

In the FM 2.0 events content you may find special conditions like indeterminate devices or bi-directional subsources.

Indeterminate devices - The FeederChangedEvent.Indeterminate property contains a list of indeterminate devices. These are devices where getting the before and after diffs would be too expensive, so the process stops and the event content labels these devices as "indeterminate". For example, tie devices on the feeder being edited often show up as indeterminate.

Bi-directional subsources- Whenever you get into a situation where subsource feeder levels fail to determine a single direction of flow through a subsource, you will see FM events fail to get reliable events until the feeder levels are corrected. Instead, you might get a single FM event that alerts you to the bi-directional subsource condition. The ArcFM Configuration Guide explains subsource levels in more detail in the Extended Feeder Manager Definitions topic.

Send Comment to ArcFMdocumentation@schneider-electric.com