[JDEV] JabberCOM Question

[Appleweed]

Ask and ye shall receive! :)

I got one of my close buddy's to take a look at JabberCOM today. He is just 
such a VC++/COM "guru" and identified the issues in less than 3 minutes. 
(Seriously. I spent 4 hours the day before... heh. No big deal... had 
nothing else to do but work. :)

There seems to be at least two problems. But at least they are easy to 
understand.
1. In JabberCOM, IXMLNode is a derived class from IDispatch (as I can see 
from the type library header file [JabberCOM.tlh] that VC++ generated when 
it tried to import the COM object.) IXMLNode contains several virtual 
member functions. Before you create any new objects with this class you 
need to define another class that actually implements these virtual 
functions or else you get "error C2259" at the point you tried to create an 
instance of IXMLNode. This error is followed by *many* errors of type 
"error C4259".

Later in the code, the IXMLTag class is derived from IXMLNode, but this 
class *does not* implement the virtual functions of IXMLNode. Instead, it 
creates a few more to go along with those functions it inherited. Finally, 
the IJabberAgents class is derived from IDispatch and it tries to create an 
instance of IXMLTag, which fails since the virtual functions were never 
implemented.

Here is a clearer view:

IXMLNode : IDispatch
{
  // bunch of virtual stuff...
  virtual HRESULT _stdcall func1() = 0;
}

IXMLTag  : IXMLNode:
{
  // more virtual stuff...
  virtual HRESULT _stdcall func2() = 0;
}

IJabberAgents : IDispatch
{
  // even more virtual stuff, with one exception here:
  virtual HRESULT _stdcall Add (
    struct IXMLTag Tag,  // <--- this is an error, since no virtual 
functions were ever implemented
    struct IJabberAgentItem * * Agent ) = 0;
}

... somewhere, maybe in IXMLTag, a fully implemented class needs to be 
created.

2. There also seems to be a few cases where a prototype declares parameters 
to be passed of one type, but when implemented the parameters are actually 
of another type.

ex:
function something (int *, char *);

function something (BSTR, struct IXMLTag)
{
  //stuff
}

This caused the MFC class wizard to comment out all the methods involved. 
Solving this takes tracing the code and matching parameter-for-parameter 
between prototype and implemented function.

---

I have a project in mind that I'm working on currently. Has to do with 
gaming and the ability of Jabber to associate data sources "out-of-band" 
across its distributed architecture. I could really use JabberCOM to 
quickly prototype my client, so I'll see what I can do to help out and fix 
the above problems. Might have to port the whole thing to C++ (which, of 
course, defeats the whole purpose of COM in the first place :P ), but I 
would hafta write the code anyway if I don't.

Will be a good challenge. Haven't looked at Pascal-like code for a long 
time.

Hey... and please don't take my above points as a slight towards you. I 
think what you created is awesome and I've seen at least two 
fully-functional clients that have benefited from it! :)

-Omar Abdelwahed

-----Original Message-----
From:	peter at vantek-corp.com [SMTP:peter at vantek-corp.com]
Sent:	Thursday, July 20, 2000 11:51 AM
To:	jdev at jabber.org
Subject:	Re: [JDEV] JabberCOM Question

Omar -

There are some serious issues with regard to using JabberCOM inside of a
VC++ project. Apparently, it looks like the events do not get imported
properly and you would have to handle them manually. This happens because
JabberCOM is a "raw" COM Object, not an ActiveX control.

This is a long standing issue, and I'd love for a VC++/COM guru to generate
some sample code that others can use as a template. Unfortunately, my VC++
knowledge is VERY VERY limited :(

Peter Millard.

_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev