[omniORB] Duplicated Values

[Wernke zur Borg]

Hi Curtis,

Your double values do appear in the message, e.g. 0x000000000840 = 3.0

The cause for your trouble is that you did not allocate memory for your
string with CORBA::string_dup. Do it and your problem will be solved.

Regards, Wernke

> -----Original Message-----
> From: omniorb-list-bounces at omniorb-support.com 
> [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf 
> Of Curtis Hawthorne
> Sent: 01 November 2005 17:19
> To: omniorb-list at omniorb-support.com
> Subject: [omniORB] Duplicated Values
> 
> Hi all,
> 
> I've been having a problem with OmniORB.  I've created what 
> should be a
> simple function one-direction call that takes a string and 6 doubles.
> The problem I'm having is that the string will get passed 
> just fine, but
> whatever the first double in a series of doubles is will be duplicated
> to the rest.  That's kinda hard to explain, so here's some examples:
> 
> "pitch", 1, 2, 3, 4, 5, 6
> 
> shows up on the other side as
> 
> "pitch", 1, 1, 1, 1, 1, 1
> 
> Also:
> 
> 1, 2, 3, 4, 5, 6, "pitch"
> 
> gives
> 
> 1, 1, 1, 1, 1, 1, "pitch"
> 
> And finally, out of desperation, I tried:
> 
> 41, "pitch", 2, 3, 4, 5, 6
> 
> which resulted in:
> 
> 41, "pitch", 2, 2, 2, 2, 2
> 
> Here's the IDL definition of the function:
> 
> void tunePID(in double p, in string pidname, in double i, in double d,
> in double setpoint, in double integral_limit, in double output_limit);
> 
> And I call it as:
> 
> pids_remote->tunePID(41,"pitch",2,3,4,5,6);
> 
> And here's the output of ORBtraceLevel=40 for that call:
> 
> omniORB: sendChunk: to giop:tcp:10.31.151.63:32824 128 bytes
> omniORB:
> 4749 4f50 0102 0100 7400 0000 1400 0000 GIOP....t.......
> 0300 0000 0000 0000 0e00 0000 fec6 9167 ...............g
> 4300 005f e600 0000 0000 0a30 0800 0000 C.._.......0....
> 7475 6e65 5049 4400 0000 0000 0000 0000 tunePID.........
> 0000 0000 0080 4440 0600 0000 7069 7463 ......D at ....pitc
> 6800 202e 2e2e 2e2e 0000 0000 0000 0040 h. ............@
> 0000 0000 0000 0840 0000 0000 0000 1040 ....... at .......@
> 0000 0000 0000 1440 0000 0000 0000 1840 ....... at .......@
> 
> So, as far as I can tell, it's reserving space in the packet for the
> other doubles, but isn't putting them in.
> 
> Any help would be greatly appreciated.
> 
> Thanks!
> 
> Curtis H.
>