Subclassing White.Core.Application

Sep 11, 2011 at 8:03 AM


Is it possible to subclass White.Core.Application. I'm confused as it provides a protected constructor along with virtual methods/properties but the core constructor is private along with state like the ApplicationSession and WindowFactory and I can't seem to get a subclass to instantiate properly. The reason I ask is I want to add application specific functionality. For example if I was automating Visual Studio I'd like to create the following subclass..

public class VisualStudio : Application

public VisualStudio Luanch(){....}

 public void OpenNewProject( String projectName ){ .... }


and then use it as follows... 

VisualStudio newVSInstance = VisualStudio.Launch();

newVSInstance.OpenNewProject( "myproject.sln");

Sep 12, 2011 at 7:20 AM



why not use Extension Methods from c# to add new operations to existing classes?




Sep 12, 2011 at 8:46 PM
Edited Sep 12, 2011 at 9:01 PM

Hi Throndorin,

Thanks for your reply. I'm looking to add application specific functionality rather than functionality relevant to all applications (which White.Core.Application already does well).

For example, I don't want the end user to have to know the exe path for each application I'm implementing as I can do the install location lookup in the registry myself. Taking the Visual Studio idea again..


is clear, an extension like


less so, and then if I want more than one application implementation if fails. For example...



makes sense but extension method Application.Launch() can only use one path internally. Also going with the previous posts example given something like..

VisualStudio vs = VisualStudio.Launch();

VSProject vsp = vs.OpenNewProject( "myproject.sln" );

OpenNewProject(..) makes sense for Visual Studio but not for Notepad so a White.Core.Application extension method OpenNewProject(..) doesn't make sense.

So at the moment I'm wrapping an Application object in each application implementation which is OK for adding new functionality but to expose the composed Application objects existing functionality with this method I have to wrap each of its methods without adding any functionality which is pointless.. what I really want is to subclass Application directly. I'm hoping I am missing something and this is possible.

public class VisualStudio : IDisposable 


      protected Application m_Application; // 

      protected VisualStudio( Application application)


m_Application = application;


      public static VisualStudio Launch( )


        Application application = Application.Launch( "visual_studio_path_goes_here" );

return new VisualStudio( application );


      // here's the problem i have to wrap existing Application methods when I'm not typically adding any functionality to them

      public Window GetWindow( String title )


return m_Application.GetWindow( title );


      public void Kill()


m_Application.Kill( );


      // etc.


Then the same applies for Notepad and any other application I want to implement. Boo! Anyone, have a different idea/pattern?

Oct 12, 2011 at 2:09 AM

In our project we use the white source code and we modified the Core.Application class to suit our requirements.

public class WindowsApplication :Core.Application , IDisposable


Oct 12, 2011 at 4:38 PM

Hi loganathan,

Thanks for your suggestion and yup that would do it :-) I guess my question stemmed from the fact that I didn't particularly want to go down this route for a number of reasons. I'm a big fan of 'if it ain't broke don't fix it' when it comes to code I didn't write. I'd prefer to extend white rather than modify it as there will be less overhead that way. If I did modify I'd need to take the time to understand the project internals and do regression testing to make sure any changes I made didn't break existing functionality (fair enough the existing nunit tests should cover most issues here) but something always crops up. Also integrating any future release will be a pain once I touch the source. Anyhow, its a possible approach if you have the time to do it. I guess I'm hoping for a simpler design solution.