Official RIVA thread

[brianmount]

Dean, is there somewhere I can download the latest RIVA header file with the definitions used by the progress bar command?

[wuench]

Oh, you meant a move while it was being held down. If it's not sending you anything, then I don't think you ever got a press inside the widget. It would only send you something if you got the original press inside the widget. Otherwise it won't be tracking the widget and therefore it won't send anything.

That also kind of leads me to believe that maybe it's related to positions on the click. And that would also maybe explain what's happening, because it sees that first press as a release, so it thinks it's being RELEASED inside the button, and asks you to draw the unpressed image. After that, it gets into sync and works. Then, after a move, somehow, it's getting into that thinking it's pressed state again.

So maybe it's something like that, and it's just that I'm compensating for it unknowingly or something. I'll look at that.

I did some testing on the button press issue using the IPhone client yesterday. Here is the process I went through and results:

--- Test 1 - Simple Button Press ---
Press Button1 - Does not highlight
Release Button1 - Command takes effect
Press Button1 - Highlights
Release Button1 - Command takes effect

--- Test 2 - Moving In/Out of Button ---
Press Button1 - Does not highlight
Slide finger out of button1 - No effect
Slide finger into button1 - No effect
Release - Command takes effect, button does not highlight

--- Test 3 - Alternating Buttons ---
Press Button1 - Does not highlight
Release Button1 - Command takes effect
Press Button2 - Does not highlight
Release Button 2 - Command takes effect
Press Button1 - Does not highlight
Release Button1 - Command takes effect

So in summary, the first button press on a button never works. Subsequent ones do but if I press another button in-between it doesn't. If I get a chance I may take some sniffer traces to get more detail. Also, I think it might be a better user experience if commands happened on button down and not release that would make commands appear to happen faster to the user.

[Fonceur]

I think it might be a better user experience if commands happened on button down and not release that would make commands appear to happen faster to the user.

It would, but then the Release might happen on a different template, which shouldn't matter with the command moved to the Press, but... That would also interfere with the Press/Move/Release, which might be even trickier...

[Dean Roddey]

You can choose to put commands in OnPress or OnClick. I usually use OnClick because it gives you a chance to back out if you want. Just move your finger out of the button and release. And this is how Windows works as well. Things don't happen on the press, they happen only if you press inside the thing and release inside the thing. So I figure folks are used to that scheme.

[wuench]

Ah cool. OnPress, I should've remembered that. It would cut the response time of commands in half, so I think the interface would seem a lot snappier. I was only playing with pause/play so for that it would work. I could see how it could cause unexpected behavior for widgets that would make interface changes like popups etc.

[Dean Roddey]

I did some testing on the button press issue using the IPhone client yesterday. Here is the process I went through and results:

And if you do one button twice and it starts responding, then you move out and just click anywhere, not on a widget, and then come back, does it still hilight or does it take two clicks again?

[wuench]

And if you do one button twice and it starts responding, then you move out and just click anywhere, not on a widget, and then come back, does it still hilight or does it take two clicks again?

It highlights.

Click Button1 - no highlight
Click Button1 - highlight
Click base template
Click Button1 - highlight

[wuench]

OK, took some sniffer traces and I think I already see the problem. The server is indeed sending the unpressed button info twice on the first click. I haven't actually decoded the traces yet, this is just looking at the behavior of the traces and the readable text.....

In comparing the traces between the Iphone and the windows RIVA client the big difference is, you have a mouse in the windows client. When you click a button in the windows client it is always preceeded by mouse move messages. But in the Iphone client you just get the press.

So to test my theory I loaded the IPhone riva client and instead of clicking a button directly I touched on the template and slid my finger onto the button. Then pressed it. It highlighted properly. So I think the server is expecting a move message into the object before a click otherwise it sends the unpressed info twice.

[Fonceur]

So to test my theory I loaded the IPhone riva client and instead of clicking a button directly I touched on the template and slid my finger onto the button. Then pressed it. It highlighted properly. So I think the server is expecting a move message into the object before a click otherwise it sends the unpressed info twice.

Seems like a reasonable explanation. Not how it should work, but how it probably does...

[Dean Roddey]

Hmmm... then perhaps the issue is that the server is using the last mouse move position and not the position sent in the press. That would 'splain it. I'll look at that. I don't think that it expects a move into the widget, since the same engine is used by the regular IV and it runs on touch screens all the time. It's probably just the RIVA server not using the press position or something like that.