Board index » delphi » D2007: Sequence of Complex Extended Type Failure

2007-08-27 11:58:19 PM
delphi32
I have a sequence of complex derived type, which produces the correct
types and structures in Delphi - however the array in delphi is always
created with 4 entries with all nil, irrespective of how many actually
occur.
THe following PHP shows the code for two of the functions I am serving:
function doGetConversation($Reference) {
$tow = new StdClass();
$t->Reference = $Reference;
$t->Identity->Id = 1234;
$t->Identity->Train = "TRAIN01";
$t->Identity->Client = 42;
$t->Identity->Module = "BOB";
$t->MessageInfo[0]->Sender = "remote";
$t->MessageInfo[0]->TimeStamp = "2007-07-31T01:12:44.944Z";
$t->MessageInfo[0]->Progress = 1;
$t->MessageInfo[0]->Position = 1;
$t->MessageInfo[1]->Sender = "base";
$t->MessageInfo[1]->TimeStamp = "2007-07-31T01:12:44.944Z";
$t->MessageInfo[1]->Progress = 1;
$t->MessageInfo[1]->Position = 1;
$t->MessageText = "Free to move";
return($tow);
}
function doGetConversationList($Reference) {
$t = new StdClass();
$t->Reference[0] = "AAAA12345678901234567890";
$t->Reference[1] = "BAAA12345678901234567891";
$t->Reference[2] = "CAAA12345678901234567892";
$t->Reference[3] = "DAAA12345678901234567893";
return($t);
}
The following calls:
P:=GetMessagePort;
RL:=P.doGetConversationList('ABC');
M:=P.doGetConversation(R);
Memo1.Lines.Add(R);
Memo1.Lines.Add(RL[0]);
Memo1.Lines.Add(RL[1]);
Memo1.Lines.Add(RL[2]);
Memo1.Lines.Add(RL[3]);
Memo1.Lines.Add(M.MessageText);
Memo1.Lines.Add(M.Identity.Train);
Memo1.Lines.Add(inttostr(low(M.MessageInfo)));
Memo1.Lines.Add(inttostr(high(M.MessageInfo)));
Memo1.Lines.Add(inttostr(M.MessageInfo[0].Progress));
Memo1.Lines.Add(inttostr(M.MessageInfo[0].Position));
Memo1.Lines.Add(M.MessageInfo[0].TimeStamp.NativeToXS);
Produce:
Memo1
AAAA12345678901234567890
AAAA12345678901234567890
BAAA12345678901234567891
CAAA12345678901234567892
DAAA12345678901234567893
Move 100km
TRAIN01
0
3
0
0
<---- AV error
Debug shows M.MessageInfo is
(([], nil, remote, nil, 0, 0), ([], nil, remote, nil, 0, 0), ([], nil,
remote, nil, 0, 0), ([], nil, remote, nil, 0, 0))
It should return two elements.
Any help would be appreciated.
Thanks.
 

Hello Christopher,
I might need a little more information to help investigate the issue here.
Would it be possible to see the data structures in Delphi and the XML being
sent over. I suspect there's a problem in the way Delphi is deserializing
the data that came over the wire. Is that right?
Cheers,
Bruneau.
 

Jean-Marie Babet writes:
qc.codegear.com/wc/qcmain.aspx
Thanks again for helping out.
 

Hello Christopher,
I posted something about this yesterday. The service on the other end is an
rpc|encoded service, right? And yet it is using attributes in complex types.
I don't think that is valid. At least it did not use to be. SOAP Encoding
allows for some predefined attributes (such as 'id' and 'href') but does not
embrace the flexibility afforded by XML schema regarding complexType
attributes.
Please let me know if I am missing something.
Cheers,
Bruneau.
"Christopher Burke" <XXXX@XXXXX.COM>writes

To clarify, I originally worked with RPC/Enc because I could get nothing
else to work at all.
I am now in doc/lit mode ... or trying hard to be :)
RPC/Enc had Delphi at least write the code correctly, Doc/Lit arrays are
not being coded correctly.
But there is a way to go at the moment :)
Thanks for your help.
Jean-Marie Babet writes:

Thanks. Yes, earlier versions of Delphi handled rpc|encoded much better but
ultimately the type of service depends the requirements of the service. The
schema you posted in the other thread
(mars.craznar.com/sample/SampleSchema.xsd) clearly point to doc|lit.
I clearly can not make that work if 'soDocument' is not enabled in the Delphi
Runtime.
I did not investigate further but I believe I mentioned that I tried
non-Delphi importers on the WSDL and they reported errors. Sadly, we don't
do much validation on WSDLs.
Based on what I have seen so far, Delphi should be able to handle what you're
after (except for the restricted/enumeration attributes are still exposed as
plain string issue I mentioned in the other post). that is an importer issue.
The runtime will handle it just fine if the importer mapped to an
enumeration. I have tweaked the importer generated code in some cases to
work around this... Or you can just make sure that the strings you set match
one of the enumeration.
Cheers,
Bruneau.