I recently worked through a customer issue that revolved around a page that reloaded itself when a form was submitted. This is a pretty common scenario, but it can be a little tricky to handle in OpenSpan, especially if the reloaded page doesn’t actually create any new elements to wait upon. The trick is to wait for the Destroyed event to fire on the web page after you call the method that triggers the reload. This is pretty easy to do in an automation by using the “Wait for this event” feature.

First, drag the Destroyed event from the page onto the automation surface. Right click and select for “Wait for this event”. The event will now transform into an object you can wait for.

_{Selecting the “Wait for this event” command}

_{The right way to trigger the event.}

_{The wrong way to trigger the event.}

_{The complete solution.}

As you can see, waiting for an event is very easy in an automation, but how would you accomplish the same thing in code? You could spin your own eventing mechanism, but this would be a fair amount of work and require a good knowledge of threading. Fortunately there is another way to access the wait for event functionality. Every OpenSpan control supports a GetEvent method which takes a special EventName object. This method actually pre-dates the automation “Wait for this event” functionality. GetEvent takes a parameter of type EventName which is simply a wrapper around the name of the event. GetEvent returns an Event object which exposes a Wait method. Events objects are managed internally by the control so you do not have to worry about disposing the object. The following code snippet illustrates how to use GetEvent.

public void DoSearch(){ // Get event Event waitForDestroy = mSample.EventSamplePage.GetEvent(new EventName("Destroyed"));

 // Perform click mSample.Next.PerformClick();

 // Wait for event if (waitForDestroy.WaitForEvent(10000)) {  // Next steps } else {  // Handle error }}

As I mentioned in my last post, I’ve been working on a sample where I host OpenSpan adapters inside of a WPF Prism application. Here’s a screenshot that will help give you a sense of it.

When I started fleshing out the sample, I realized that WPF didn’t provide an object that implemented ISynchronizeInvoke that I could pass to the adapter Start method. As a little background, we added an overload to the Start method that takes an instance of ISynchronizeInvoke as a convenience for developers using adapters within windows forms applications. Normally, within the OpenSpan runtime, adapters fire asynchronous events on thread pool threads. Our automation surface abstracts the invocations required to interact with windows forms from visual developers.

When hosting adapters directly in .NET, we quickly realized that it was painful to force developers to invoke onto the windows forms thread anytime they needed to update their UI within an adapter event. Thus, we added an overload to the Start method where developers could pass in an instance of ISynchronizeInvoke. In practice, since all windows forms controls implement ISynchronizeInvoke, developers simply pass in their form or user control. When an adapter is started with an instance of ISynchronizeInvoke, it will automatically invoke all events onto the right thread.

However, the WPF Dispatcher object, which provides equivalent functionality to ISynchronizeInvoke, does not actually implement ISynchronizeInvoke. A quick search revealed that other folks had run into the same issue with WPF and created wrappers. However, looking over the wrappers, they weren’t entirely complete. It seems that nobody had implemented every method or property required. In particular I knew that our adapters depended on the EndInvoke method and the IAsyncResult.AsyncWaitHandle property.

To remedy this, I implemented my own wrapper. In addition to the public DispatchWrapper, I created a couple of nested private classes, DispatchOperationWrapper and DispatcherOperationWaitHandle, to hide the IAsyncResult and WaitHandle implementation details. Unlike some of the samples I found the implementation below doesn’t use any looping or sleeps to wait. Also note that the implementation for IAsyncResult.CompletedSynchronously always return false. This conforms to the IAsyncResult guidance on MSDN.

using System;using System.Threading;using System.Windows.Threading;

namespace OpenSpan.Samples{ public class DispatcherWrapper : ISynchronizeInvoke {  private Dispatcher _Dispatcher;

  public DispatcherWrapper(Dispatcher dispatcher)  {   _Dispatcher = dispatcher;  }

  #region ISynchronizeInvoke Members  public IAsyncResult BeginInvoke(Delegate method, object[] args)  {   DispatcherOperation op = _Dispatcher.BeginInvoke(method, args);   return new DispatcherOperationWrapper(op);  }

  public object EndInvoke(IAsyncResult result)  {   DispatcherOperationWrapper wrapper = result as DispatcherOperationWrapper;   if (wrapper != null)   {    wrapper.Operation.Wait();    return wrapper.Operation.Result;   }   throw new ArgumentException("Result does not wrap a DispatchOperation");  }

  public object Invoke(Delegate method, object[] args)  {   return _Dispatcher.Invoke(method, args);  }

  public bool InvokeRequired  {   get { return _Dispatcher.CheckAccess(); }  }

  #endregion

  private class DispatcherOperationWrapper : IAsyncResult  {   private DispatcherOperationWaitHandle _WaitHandle;   private DispatcherOperation _Operation;   private object _State;

   public DispatcherOperationWrapper(DispatcherOperation operation)   {    _Operation = operation;   }

   public DispatcherOperationWrapper(DispatcherOperation operation, object state)    : this(operation)   {    _State = state;   }

   public DispatcherOperation Operation   {    get    {     return _Operation;    }   }

   #region IAsyncResult Members   public object AsyncState   {    get { return _State; }   }

   public WaitHandle AsyncWaitHandle   {    get    {     if (_WaitHandle == null)     {      _WaitHandle = new DispatcherOperationWaitHandle(_Operation);     }     return _WaitHandle;    }   }

   public bool CompletedSynchronously   {    get { return false; }   }

   public bool IsCompleted   {    get { return (_Operation.Status == DispatcherOperationStatus.Completed); }   }   #endregion

   private class DispatcherOperationWaitHandle : WaitHandle   {    private DispatcherOperation _Operation;

    public DispatcherOperationWaitHandle(DispatcherOperation operation)    {     _Operation = operation;    }

    public override bool WaitOne()    {     DispatcherOperationStatus status = _Operation.Wait();     return (status == DispatcherOperationStatus.Completed);    }

    public override bool WaitOne(int milliseconds)    {     return this.WaitOne(new TimeSpan(0, 0, 0, 0, milliseconds));    }

    public override bool WaitOne(int milliseconds, bool exitContext)    {     return WaitOne(milliseconds);    }

    public override bool WaitOne(TimeSpan timeout)    {     DispatcherOperationStatus status = _Operation.Wait(timeout);     return (status == DispatcherOperationStatus.Completed);    }

    public override bool WaitOne(TimeSpan timeout, bool exitContext)    {     return this.WaitOne(timeout);    }   }  } }}

Francis had an interesting post earlier this week: Not using OpenSpan? You could be losing millions. His basic premise is that if you’re not using OpenSpan, you’re losing millions of dollars. The funny thing is that he’s right. This isn’t just hyperbole. Our customers really do save millions of dollars. So why isn’t the world beating a path to our door? Simply put, it’s because the technology community thinks we are the “wrong” way of solving problems.

Are your users having to cut and paste and toggle between too many applications? An OpenSpan developer can develop a solution to that problem in minutes and deploy it in days. But the “right” way of solving that problem is to integrate the applications on the back-end and provide a new user interface. How long is that going to take? I bet it’s longer than a few days.

Are your users having to navigate between too many screens to complete a task? An OpenSpan developer can develop a solution to that problem in minute and deploy it in days. But the “right” way of solving that problem is to rewrite the application and provide a better user interface. How long is that going to take? I bet it’s longer than a few days.

I could keep going, but I think you get the picture. Of course, the real question is what is “right”? If “right” is defined as the most elegant solution that will be most extensible in the future, then OpenSpan is the wrong solution. If “right” is defined as the most cost-effective and rapid solution that will provide value to the business, then OpenSpan is the “right” solution.

Ultimately, the “right” answer it to do both. Solve the business problems in the short term with OpenSpan and in the long term with your strategic architecture. Most IT organizations have backlogs that contain thousands of feature requests. Usability issues, unless they are absolutely horrendous, almost always get pushed below strategic features. And with the resources available and the time alloted, that’s the right decision. Many of those big features will save hundreds of millions of dollars. While those pesky little features are only worth tens of millions of dollars.

But why waste those tens of millions of dollars when you could implement them quickly and cheaply with OpenSpan? Just today, we had a deal killed by a CTO who said, “Don’t worry about that, we’re reimplementing that application anyway. It’s a waste of money.” Really? It’s a waste of money to buy a product where the ROI is typically delivered in less than three months? Whose cost of ownership is a tenth of the savings it delivers? That enables a team of less than five developers to save a company millions?

I try not to criticize the organizations we sell to, but it’s incredible the narrow attitudes that prevail in our industry. Real agile practitioners know that you get the best results by delivering value rapidly. Every day, I tell my team to ask themselves “What’s the value of what I’m doing? Is there anyway I can deliver the same value better or faster?” Although agile is on the rise, it seems clear that the core principles behind agile have yet to filter up to the decision makers within organizations.

Here’s the bottom line: If you’re not using OpenSpan, you’re not delivering the value you should deliver. You’re wasting money and you’re hurting your business.