conceptual inertia

Applications typically have some type of project file format. For example, Maya saves scenes using a binary file:

This file type is associated with Maya, it has the .mb extension and a custom icon. Double-clicking the file will open it in Maya. Today, we’re going to associate TestApp with the .testapp extension:

To associate a file type, you need to do three things:

1. Add the file extension and associated application to the registry.
2. When double-clicking a .testapp file, determine whether an instance of the associated process is already running.
3. If the application is already running, pass the file across process boundaries.

The first step is easy and makes use of the following Win32 functions to create and set entries:

• RegOpenKeyEx
• RegCreateKeyEx
• RegSetValueEx

The code to create key/value pairs in the registry is straightforward. Therefore, I’m not going to list it here so please reference the source code included in today’s download.

After executing the registration code, you should have new keys under HKEY_CLASSES_ROOT with the following structure:

And a new TestApp key where we assoicate the file with a default icon (which is indexed at 0 as an embedded resource in the executable):

The executable to launch is set under the Command section, with %1 being the command line param:

Use RegEdit to verify the above entries after executing today’s demo. To execute RegEdit use the Run prompt:

Once the file associations have been added to the registry, the next thing to do is determine if an instance of TestApp is running. The Process class in the System::Diagnostics namespace makes this step trivial.

So how does one application communicate with another across process boundaries? Under Win32 you use named pipes. A pipe connects two ends together – a client and server. Under .NET, named pipes have been wrapped up in the System::Runtime::Remoting::Channels::Ipc namespace. An IpcChannel is used when one application needs to communicate with another application in a different process on the same machine.

However, before we look at inter-process communication (IPC) let’s have a look at class SimpleFile which represents our .testapp file format.

public ref class SimpleFile : public MarshalByRefObject
{
    public: delegate void LoadDelegate(SimpleFile^ simpleFile);
    private: LoadDelegate^ loadDel;

    public: event LoadDelegate^ LoadEvent
    {
        void add(LoadDelegate^ value)
        {
            loadDel += value;
        }

        void remove(LoadDelegate^ value)
        {
           loadDel -= value;
        }
    }
 

Remoting is used for communication between app domains. An app domain is a logical container for a .NET applciation and is often refered to as a “lightweight process”.

The same remoting mechanism is used between two app domains whether those app domains are in the same process, in different processes on the same machine, or different processes on different machines. Any type that wants to expose its availability across app domains must inherit from MarshalByRefObject or be serializable.

To keep things as simple as possible, the SimpleFile “format” only contains a single value, which is parsed and stored:

private: int ultimateAnswer;
public: property int TheAnswerToTheUltimateQuestionOfLifeTheUniverseAndEverything
{
    int get() { return this->ultimateAnswer; }
}

public: void Load(String^ filePath)
{
    XmlTextReader^ xtr = gcnew XmlTextReader(filePath);

    while( xtr->Read() )
    {
        if( xtr->NodeType == XmlNodeType::Element )
        {
            if( xtr->Name == "UltimateAnswer" )
            {
                xtr->Read();
                this->ultimateAnswer = int::Parse(xtr->Value);
            }
       }
    }

    xtr->Close();
    delete xtr;

    if (loadDel != nullptr)
        loadDel(this);
}
 

Here we see the value stored in the sample file foobar.testapp:

The constructor in the Form class is overloaded to accept an array of arguments:

public: Form1(array<String^>^ args)
{
    InitializeComponent();

    // - in this example, we register the file type associations every time
    //   the application runs (overwriting keys)
    // - however, you would normally do this only once as part of your
    //   installation process
    RegisterFileAssociations();

    // - cache any arguments passed from Main
    this->args = args;
}
 

If there were no arguments passed, the application is starting up for the first time.

private: System::Void OnFormLoad(System::Object^ sender,
                                 System::EventArgs^ e)
{
    // - application is loading for the first time
    if( args->Length == 0 )
    {
        RegisterService();
    }
 

The host or server has to tell .NET which object’s it’s willing to expose. These objects or well-known types are registered using the static method RegisterWellKnownServiceType of the RemotingConfiguration class.

The host also has to register a channel with ChannelServices. A channel will monitor a port and accept incoming calls, servicing those calls with a thread from the thread pool. The IpcChannel is a welcome addition because prior versions of .NET provided only the TcpChannel and HttpChannel for communication. Both TcpChannel and HttpChannel have associated overhead for the network stack regardless if the communication taking place is on the same machine or across a network. IPC provides a direct line, reducing overhead and increasing performance.

private: void RegisterService()
{
    BinaryServerFormatterSinkProvider^ serverProv = 
        gcnew BinaryServerFormatterSinkProvider();
    serverProv->TypeFilterLevel = TypeFilterLevel::Full;

    Hashtable^ properties = gcnew Hashtable();
    properties["portName"] = "SimpleFileServer";

    IpcChannel^ ipc = gcnew IpcChannel(properties, nullptr, serverProv);
    ChannelServices::RegisterChannel(ipc, false);

    RemotingConfiguration::RegisterWellKnownServiceType(
                                      SimpleFile::typeid,
                                      "SimpleFile.rem",
                                      WellKnownObjectMode::Singleton);

    file = (SimpleFile^)Activator::GetObject(
                                      SimpleFile::typeid,
                                      "ipc://SimpleFileServer/SimpleFile.rem");

    file->LoadEvent += gcnew SimpleFile::LoadDelegate(this,
                                                      &Form1::OnProjectFileOpen);
}
 

During server registration, a SimpleFile is activated and its LoadEvent is hooked up to the following:

private: delegate void InvokeDelegate(SimpleFile^ simpleFile);
private: void OnProjectFileOpen(SimpleFile^ simpleFile)
{
    // cross-thread op
    array<Object^>^ arr = { simpleFile };
    this->Invoke(gcnew InvokeDelegate(this, &Form1::ProcessFile), arr);
}

public: void ProcessFile(SimpleFile^ simpleFile)
{
    this->label2->Text =
        simpleFile->TheAnswerToTheUltimateQuestionOfLifeTheUniverseAndEverything.ToString();
}
 

Invoke is used to update the Form’s user interface. Execution has to take place on the caller’s thread to avoid a cross-thread exception.

Back to OnFormLoad, where a list of processes is then assembled. It’s possible the process was launched with a double-click on a .testapp file. If so, services need to be registered and a SimpleFile loaded:

array<Process^>^ processArray =
    Process::GetProcessesByName(Process::GetCurrentProcess()->ProcessName);

// application loading for the first time from a double-click on file
if( processArray->Length == 1 )
{
    RegisterService();

    SimpleFile sf;
    sf.LoadEvent += gcnew SimpleFile::LoadDelegate(this,
                                                   &Form1::OnProjectFileOpen);
    sf.Load(filePath.ToString());
}
 

Otherwise, a process is already running and SimpleFile needs to get its information across process boundaries. Here we see the client registering an IpcChannel and activating the well-known file (SimpleFile):

else if( processArray->Length > 1 )
{
    MessageBox::Show("Instance already running, passing args along");

    for each( Process^ p in processArray )
    {
        if( p->Id != Process::GetCurrentProcess()->Id )
        {
            try
            {
                IpcChannel^ ipc = gcnew IpcChannel("SimpleClient");
                ChannelServices::RegisterChannel(ipc, false);

                SimpleFile^ file =
                    (SimpleFile^)Activator::GetObject(
                                        SimpleFile::typeid,
                                        "ipc://SimpleFileServer/SimpleFile.rem");

                if (file == nullptr)
                {
                    MessageBox::Show("Failure to connect with remote server");
                    this->Close();
                }

                file->Load(args[0]);
                this->Close();
            }
            catch(Exception^ e)
            {
                MessageBox::Show(e->Message);
            }

        } // end if

   } // end for each

} // end else if
 

In summary, the application is now assoicated with a file type. Double-clicking the file will launch the app. If the app is already running, IPC will be used to pass the file info across process boundaries, allowing the application already running to open the file as a new “project”.

Build and run the demo once to associate the file type in the registry. If you don’t see a blue icon for “foobar.testapp”, hit F5 in the explorer window to refresh it. Shut down the application and then try double-clicking various files with the .testapp extension.

You can download the source here.