Showing posts with label COM. Show all posts
Showing posts with label COM. Show all posts

Thursday, January 3, 2019

Fin@Home - Demo Finance Application featuring Desktop, Web and Native Mobile Platforms.

A demo finance application featuring Desktop, Web and Native Mobile [Android, Java Feature Phone (J2ME) ] Platforms. The below technologies have been used to build this application;


Mobile

  • Android Native Programming through Android SDK
  • Feature Phone Programming through J2ME/Java Midlet SDK

Desktop

  • Microsoft Access 2007+ Database Technologies
  • Visual C++ 6 (MFC, ATL, WTL - COM/Active X Technologies)
  • Visual Basic 6 (Active X Technology)
  • HTML/CSS


This suite contains demo features, to add your daily expenditures, investments, insurance policies, scheduled tasks etc. A brief Reporting model on each of the above categories have been provided for viewing a consolidated summary


The project is hosted on GitHub - Link: https://github.com/avarghesein/FinHome


alt Main Application

Saturday, October 21, 2017

ActiveX.NET, A True Out-Of-Proc(EXE) COM Server Using C#.NET

ActiveX.NET is an attempt to provide a pluggable Out-Of-Proc (EXE) COM Server in Microsoft.NET (C#).

The project has been inspired from CSExeCOMServer (hosted in Code.MSDN and probably the only one Out-Of-Proc COM Server available in Microsoft.NET !) and to provide a much more cleaner .NET Specific approach for building EXE COM Server.

The idea is to provide an advanced implementation, with the below features:

1. Introduce .NET Windows Message Pump (Application.Run) , instead of Native Message Pump

This will enable leveraging .NET Win Forms/UserControls inside COM Objects created within .NET without any restrictions

2. Decouple Out-Of-Process EXE Server and make it as a shared EXE COM Server

This will enable loading user created COM Visible Libraries dynamically

3. Help developers build COM Objects easily as Plug-Ins, targeting towards the shared EXE COM Server

Let developer build COM objects without worrying about reference counting, and registering for Out-Of-Proc use. Just enable the COM Object for Out-Of-Proc use by simply applying a few attributes and base classes.

The project is available in GitHub.

ActiveX.NET.Architecture

 

 

Tuesday, April 7, 2015

Word/Excel Properties returning NULL/Nothing, Inside Event Sinks or COM Callbacks

While working with a VSTO addin (Excel/Word Automation with .NET), I’ve faced a strange issue. The context is described here. We had a VSTO Word Ribbon AddIn, for having a word application level customization. Within the AddIn we also consume another COM Object’s Event Sources (COM event interfaces) through Event Sinks (COM Callbacks).

Within the callback function, we are trying to access word objects properties like Active Document, Document Properties, Custom document properties e.t.c. But all properties are returning NULL values for our surprise. There is no clue, regarding why its not able to access the properties and its even not throwing any error as well.

After much troubleshooting its found that the issue lies with, how .NET manages COM callbacks. By default .NET uses the built in ‘Free Threaded Marshaller’ (MTA – Multi Threaded Apartments) to handle COM Events to invoke the sinks. It will pick up a random RPC thread to handle the incoming COM event, and the Callback will be executed on this random RPC thread. COM objects in MTA are not thread safe by default. We should use our own synchronization mechanism to synchronize the access.

On the other hand, most of the COM components, that having GUI elements (like Office Word/Excel) lives in STA (Single Threaded Apartment) only, which is by default thread safe. This thread safety will be managed by the COM runtime by itself. It uses and hidden window and associated window messages to synchronize the access.

Now in our context, we’ve two apartments. One is the Office system’s STA and the .NET runtime’s MTA. The callback which is being executed in MTA needs to access the office properties, which lives in STA. COM interface access across apartments, is not directly possible. The needed interface (here Office propertie) should be marshalled to the target apartment. By default this is not available with Office objects. i.e Marshaling Office COM objects from their original STA apartment to the MTA apartment, where the callback want to access the office properties.

Since this marshalling fails, the properties returning as NULLs.

So what could be the solution? The answer is to tell the .NET runtime to use the same office STA apartment for the COM Event handling, so that both Office objects and callbacks will live in the same apartment and no marshalling needed to access the office objects.

To make the ‘Callback object’ to join the STA apartment, we need to inherit our ‘Callback object class’ from ‘StandardOleMarshalObject’ instead of the default ‘Free Threaded Marshaller’. A sample given below.

[ComVisible(true)]

[ClassInterface(ClassInterfaceType.None)]

internal class YourComCallBackClass : StandardOleMarshalObject, AComEventSinkInterface

{

       public short AComEventSinkInterface.EventSinkOrCallbackMethod()

       {

             //Access your office properties here.

             Office.DocumentProperties properties;

             properties =

             Application.ActiveDocument.CustomDocumentProperties as Office.DocumentProperties;

       }

}

ClassInterfaceType.None’ attribute is equally needed to make this work.

You can read more on this in the below links.

StackOverflow

MSDN Blogs

MSDN