[omniORB] Problem with: Dynamic Invocation Interface

[Finn B. Laustsen]

Hi,

Thanks for your help. It is working now.

I am not going to use the "private" functions - it was just my last attempt
to make it work!
I will keep in mind your words about "the complicated and slow" way of doing
things.


Thanks again 

Finn


-----Original Message-----
From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
Sent: Tuesday, February 26, 2002 11:35 AM
To: Finn B. Laustsen
Cc: omniorb-list@uk.research.att.com
Subject: Re: [omniORB] Problem with: Dynamic Invocation Interface 


On Tuesday 26 February, "Finn B. Laustsen" wrote:

> I quess that the problem lies in setting the return type with the correct
> typecode!

There are two problems in the code. One is causing the problem, the
other isn't, but it dangerous...

> 	try {
> 		char callMethod[] = "nodeName";

This is what is causing the BAD_OPERATION exception. nodeName is an
attribute, so to call it with DII you must use the name
"_get_nodeName".

> 		CORBA::Request_var req = domObj->_request( callMethod );
> 		// set return type
> 		CORBA::TypeCode_ptr tc_dom_DOMString =
> CORBA::TypeCode::PR_alias_tc("IDL:dom/DOMString:1.0", "DOMString",
> CORBA::TypeCode::PR_sequence_tc(0, CORBA::TypeCode::PR_ushort_tc()));

This is the dangerous bit. The PR_ functions in CORBA::TypeCode are
internal to omniORB. Application code should _never_ use them, and
they may not do what you expect, and their behaviour may change from
release to release. The "PR_" prefix means "private", but they have to
be public so the stubs can use them.

To create TypeCodes on the fly, you should use the ORB's TypeCode
creation methods. Alternatively, if you have the stubs for the types
available, use the generated TypeCodes, like dom::_tc_DOMString.

I'd also like to point out that using DII is almost always a bad
idea, since it makes everything so much more complicated (and
slower). It's worth re-evaluating whether you really need to use it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --