0

Does JSCallBack in Firebreath help in this matter?Because what I just saw it only handles events occured in the firebreath(native c++) project.Am I right here? I used the concept of IConnectionPoint interface to establish a connection with the outgoing interface containing the Event signatures. My code closely resembles this post.

Also I found this info regarding Connection of COM with client.Have a question here now: Does my PluginAPI class needs to implement this Outgoing interface in PluginAPI.h file? Like this, 

class PluginAPI : public FB::JSAPIAuto, public ManagedDLL::ICalculatorEvents
{
//register methods
}

If so, Then it's raising 2 errors

  1. telling cannot instantiate abstract class. Points me to these lines of make_shared.hpp

    template< class T, class A1, class A2 > boost::shared_ptr< T > make_shared( A1 && a1, A2 && a2 ) { boost::shared_ptr< T > pt( static_cast< T* >( 0 ), BOOST_SP_MSD( T ) );

    boost::detail::sp_ms_deleter< T > * pd = boost::get_deleter< boost::detail::sp_ms_deleter< T > >( pt );

void * pv = pd->address();

::new( pv ) T(         ////HERE
    boost::detail::sp_forward<A1>( a1 ), 
    boost::detail::sp_forward<A2>( a2 )
    );

and 2. to alignment_of.hpp

template <typename T>
struct alignment_of_hack
{
    char c;
    T t;        ///HERE
    alignment_of_hack();
};

Stuck here for the last 2 days. Also any workaround for this.

Community
  • 1
  • 1
Pratik Pattanayak
  • 194
  • 4
  • 23

1 Answers1

1

Don't know anything about the C# interop you're tryign to do, but I can tell you that the issue you have with "cannot instantiate abstract class" is because you are extending ManagedDLL::ICalculatorEvents and it's presumably an abstract base class, meaning that you need to implement the pure virtual functions that are in that class.

Other than that, I have absolutely no idea. One idea might be to keep your FireBreath code and your COM calling code separate, and create a class that you'll use as a bridge. Rather than making changes to your PluginCore object which is already tied tightly to firebreath, create a new object that can be the bridge and do weird things to that.

Just a thought; I think it'd simplify things, though, because then you could ask questions that would be just about the COM side or just about FireBreath. When you mix them you get into situations where people don't answer 'cause they only know one or the other and don't know how the half they don't understand may be affecting things =]

taxilian
  • 14,229
  • 4
  • 34
  • 73
  • Appreciate your reply @taxilian! The bridge(c++/cli) thing was not feasible for our solution for some reasons!As for the error, I intuitively knew that. Hope you could answer my question mentioned on the first line? – Pratik Pattanayak Jul 04 '13 at 05:22
  • 1
    no, I don't think JSCallback will help you in the slightest. Not sure what you mean that a bridge isn't feasible? You're already trying to make your PluginCore-derived object talk to it, I'm just suggesting that you create another object and use that instead of using the PluginCore object. Nice thing about that is you can test it in another app and logically seperate it from the code tied to firebreath. Similar to the pimpl pattern – taxilian Jul 04 '13 at 19:37