Official RIVA thread

[Dean Roddey]

Not sure wat da deal is there. I'll look at it.

[brianmount]

Dean,

I'm having trouble getting the environment variables to work at login. Maybe my syntax is wrong, but before we get to that problem, it seems like CQC is doing something weird. When I send this message:

<CQCGW:GetSecurityToken CQCGW:ResponseData="678272dc1af6493e64f038904179982e"><CQCGW:EnvVar CQCGW:VarNum="0"></CQCGW:EnvVar><CQCGW:EnvVar CQCGW:VarNum="1"></CQCGW:EnvVar><CQCGW:EnvVar CQCGW:VarNum="2"></CQCGW:EnvVar><CQCGW:EnvVar CQCGW:VarNum="3">b</CQCGW:EnvVar></CQCGW:GetSecurityToken>

it seems like I'm getting two messages back. First a valid AckReply:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE CQCGW:Msg PUBLIC 'urn:charmedquark.com:CQC-GWProtocol.DTD' 'CQCGWProtocol.DTD'>
<CQCGW:Msg>
<CQCGW:AckReply CQCGW:Info='EUserRole_PowerUser'/>
</CQCGW:Msg>

and then what appears to be the second part of an exception reply:

GW:File="CIDXML_SimpleTree.cpp" CQCGW:Line="957" CQCGWrocess="CQCGWSrv" CQCGW:Thread="CQCGWSrvWorkerThread0">
Got a child index of 0 but only 0 exist in this CQCGW:EnvVar element
</CQCGW:ExceptionReply>
</CQCGW:Msg>

Both returned messages have the same sequence number as the GetSecurityToken message I sent, and have valid headers (magic values and so on), but the second one has a bad checksum, and of course is missing the first part of the message. It's possible that I'm doing something stupid and losing the first part of the message myself. However, because I see that error text that I couldn't be making up myself, I think you are in fact sending me some sort of exception (maybe a valid exception message that I'm messing up).

Can you tell me what is going on, both in terms of what your returning to the message I did send, and in terms of what I should be sending instead? Let me know if I'm not being clear. Thanks.

[Dean Roddey]

It looks like it's not handling an empty environment variable element. For now, just don't send any that don't have a value and that should make it happy (let me know if not), and I'll look into that issue.

[brianmount]

Dean,

Based on trial and error, it seems like the bit flags for monthly events when using the XML Gateway are:

1: January
2: February
4: March
etc.

while the bit flags for weekly events are:

64: Sunday
32: Monday
16: Tuesday
8: Wednesday
4: Thursday
2: Friday
1: Saturday

That's fine if that's the way it is, but since they seem to run in opposite directions (monthly in increasing order, weekly in decreasing order), I thought I would double to make sure that's correct. I don't think the document made it clear.

[Dean Roddey]

From your perspective, they really aren't bits in that sense, but just indicators. But the first 1 or 0 goes into the 0th bit position on the server side's binary representation, and so on. When it gets the mask string it just loads them up that way, so in theory it should be that the 0th bit is sunday.

Is what you are seeing based on way the values come back to you after you set them in CQC, or what you see in CQC after you send them in?

[Dean Roddey]

Looking at it, it uses the weekday enumeration (sund, mon, etc...) to shift a one up and compare it to the mask. The characters in the XML string as loaded into the low order bit to the high order bit, so that should make the first one be sunday, second one monday, etc...

And when the XML GW formats them, it definitely seems to be formatting them in the same way, so sunday would be the first 0/1, monday the second, and so forth.

[brianmount]

SamVimes, can you check things again? It sounds like the intention is for Sunday to be the least significant bit rather than the most significant, but I know you had said that it appeared to be behaving differently when you looked in the system.

[Dean Roddey]

I'll double check it today also. I had the system up on the jacks yesterday so I couldn't do it.

[Dean Roddey]

So, I was wondering, would it be useful to have a System::NativeCmd() type action command that existed purely for you guys to be able to define for your own users, to send commands to the local device they are on? I'd just add it to the things passed to you. It could have up to four parameters, which could be interpreted any way you want. I'd just pass the text as entered (after any standard expansion of course.)

[brianmount]

I don't immediately think of a good use for such a feature, but maybe SamVimes has an idea.