Official RIVA thread

[Dean Roddey]

And that is the image set up as the pressed image, right? It's not set for any other of the button's image types?

[brianmount]

I'm not sure. Commander Vimes, sir, can you shed light on the image setup of the buttons on the test template?

[Fonceur]

I checked the new template message and it's working fine for me. I get the right info and whatnot. The structures are correctly within the packing pragma so it shouldn't be that the structure is not appropriate byte packed.

[Dean Roddey]

I'll check it out and see. Maybe I whacked something. Hmmm... I wonder if maybe I got it outside of the packing pragma or something (which I'd not have noticed necessarily since both of my sides would still see it the same.)

[Fonceur]

The login challenge can include an error message if the request fails. Only those structures that include text will have those extra bits at the end, but in some cases the string is empty, in which case you have an empty length. So if the c1Error field of the login challenge is set, there's a string at the end with the error message, else it's the empty one.

Just a suggestion for the RIVA 2.0 protocol, but what if you stuck with the original structure (without the Card4 padding) for the normal opCode. Then you could use opCode + X when a single text is included, and opCode + Y when 2 strings of text are included. Along those lines, let say a challenge failed and the Status structure is totally different (since there is no role or session cookies to return), then you could use opCode + Z or such... The values of X, Y, Z pretty much depends on which structures can have text, which seems to require testing to determine it... I guess if you are afraid of running out of opCode, you could either use Card4 for the opCode or add an extra Card1...

The point is that from the opCode and associated structure, we should already know how to read the message, without having to deal with different structures that should have their own opCode to start with....

[SamVimes2]

And that is the image set up as the pressed image, right? It's not set for any other of the button's image types?

Correct.

The unpressed image is enabled but not set. Nothing else is enabled.

Could somehow RIVA be confusing the pressed and unpressed images?

[Dean Roddey]

It may be that, if you remove the image, but it image slot is not disabled (in this case because it can't), that it will send a previously set image name because it's not getting cleaned out or something when the image is removed.

[Dean Roddey]

I checked the new template message and it's working fine for me. I get the right info and whatnot. The structures are correctly within the packing pragma so it shouldn't be that the structure is not appropriate byte packed.

I accidentally edited Fonceur's message above instead of doing a reply. Oops, no way to get it back now. Anyway, I tried it out and it's happy for me. Perhaps Brain can report what he's seeing.

[Fonceur]

I checked the new template message and it's working fine for me.

My bad, it seems I was reading Card2 and didn't know the template's name was appended at the end...

[Fonceur]

Does this seem like a good match for the clip mode?

c1ClipMode_And = 0; --> INTERSECT
c1ClipMode_Copy = 1; --> REPLACE
c1ClipMode_Diff = 2; --> DIFFERENCE
c1ClipMode_Or = 3; --> UNION
c1ClipMode_Xor = 4; --> XOR

I also have access to REVERSE_DIFFERENCE... It's mostly the Copy that has me worried...