Ok, so that is actually what the ToString does, but let me walk you through what all you need to send back.
Let me use your example, assuming you are calling back and want to trigger the rxmsg event SumOfTwoNumbers. My implementation would look like this, ignoring any kind of stupid proofing:
Code:
[COLOR=#0000FF]private[/color] [COLOR=#0000FF]void[/color] Startup()
{
[COLOR=#2B91AF]MicrosInterface[/color] microsInterface = [COLOR=#0000FF]new[/color] [COLOR=#2B91AF]MicrosInterface[/color](MessageHandler, 4524);
microsInterface.Start();
}
[COLOR=#0000FF]private[/color] [COLOR=#2B91AF]MicrosMessage[/color] MessageHandler([COLOR=#2B91AF]MicrosMessage[/color] message)
{
[COLOR=#0000FF]int[/color] a = [COLOR=#0000FF]int[/color].Parse(message.ApplicationData[1]);
[COLOR=#0000FF]int[/color] b = [COLOR=#0000FF]int[/color].Parse(message.ApplicationData[2]);
[COLOR=#0000FF]int[/color] result = a + b;
[COLOR=#0000FF]return[/color] message.CreateReply([COLOR=#A31515]"SumOfTwoNumbers"[/color], result);
}
And the sim file would look something like this:
Code:
event inq : 1
[indent]rxmsg 10, 5[/indent]
[indent]waitforrxmsg[/indent]
endevent
event rxmsg: SumOfTwoNumbers
[indent]var result : N12[/indent]
[indent]rxmsg result[/indent]
[indent]infomessage result[/indent]
endevent
The result of hitting the button linked to inquiry 1 would be an infomessage with 15 in it.
So obviously there is a lot more going on in the background. To explain how to implement your own create reply you have to know what Micros expects in reply. Here is the format it wants:
Code:
StartOfHeader + ID + StartOfText + FieldSeparator + ApplicationSequence + ApplicationDataString + EndOfText + CheckSum + EndOfTransmission
Lets break this down a bit..
StartOfHeader is just a symbol letting micros know that "hey, the header data starts here". I won't get into how networking works, but you normally need things like this to control when you start and stop listening. TCP handles this itself, but we're dealing with a legacy compatible stuff here. Start of header would be the character: '\x001'
Directly after the StartOfHeader, Micros expects the ID. The ID is defined as the POS uws number (either 2 or 9 digits as defined by the interface settings) and the interface name (up to 16 characters). The total length of the ID should be 27 bytes. So assuming my interface name is AddTwoNumbers and I have it set to 9 digits and am sending the message from my server which is UWS 99, my message so far looks like:
Code:
'\x001' + "000000099" + " AddTwoNumbers"
Next, to separate this header data from the actual application content we have our STX, or start of text character. So now we have:
Code:
'\x001' + "000000099" + " AddTwoNumbers" + '\x002'
After our STX, you need the field separator. Yes, even though we aren't separating anything yet, you start with this. So now:
Code:
'\x001' + "000000099" + " AddTwoNumbers" + '\x002' + '\x1C'
Now micros wants the application sequence, which is a transmission sequence number followed by a flag indicating if its a retransmit or not. If you're working with an interface that deals with things like money, you need to keep track of these sequence numbers; sometimes you will get the same sequence number twice from Micros with an R in the retransmission flag spot. If you get this, it is because Micros failed to get a response. If you already processed it, just resend the same response back. If you didn't, process it (obviously).
Code:
'\x001' + "000000099" + " AddTwoNumbers" + '\x002' + '\x1C' + "03 "
Next we include the application data. No separator here, just go straight into the application data. Its still a fixed width so far so micros knows where this starts. Documentation says you can have a max of 32K here, but I've never come close to hitting that in a single message. Keep it in mind though. This is where you put ALL your data. Start with the rxmsg event you are trying to invoke, then a field separator, and then each piece of data, separated with field separators. So in our example its:
Code:
'\x001' + "000000099" + " AddTwoNumbers" + '\x002' + '\x1C' + "03 " + "SumOfTwoNumbers" + '\x1C' + "15"
After the data you're sending back, an end of text (ETX) character is expected so micros knows that the rest of the message isn't actually data. So:
Code:
'\x001' + "000000099" + " AddTwoNumbers" + '\x002' + '\x1C' + "03 " + "SumOfTwoNumbers" + '\x1C' + "15" + '\x003'
After the end of text you should include a check sum, however, this field doesn't really matter when working in TCP. TCP has its own data validation which micros recognizes, so this is only used when your interface works over serial (which is what dictates this legacy formatting). So we're just going to leave it off. Which means our final character to include is the end of transmission character, or EOT.
Code:
'\x001' + "000000099" + " AddTwoNumbers" + '\x002' + '\x1C' + "03 " + "SumOfTwoNumbers" + '\x1C' + "15" + '\x003' + '\x004'
So that would be our entire message, so just write that back on the stream and you'll get your infomessage!
That all make sense?
