OLD FORUM - Use new one: https://www.CaptainCasa.online/forum

We've got a weird problem which we're unable to precisely pin down.

When we put links in a column in a fixgrid, sometimes some Users have to click these links two times (doesn't matter if it is a straight up doubleclick or a click-pause-click).

We've got Users to whom that never happened, Users to whom that happened, then, with an CC Framework update or Java update it disappeared or the other way around (suddenly they had that problem).

We checked the Framework versions (we just deployed), the Java versions, but we are unable to pin it down to one factor or a precise combination of factors. Sometimes of two Users with the same setup one had the problem and the other one did not.

We're (wildly) guessing that it may have to do with the way Userevents/clicks are passed from the fixgrid to subelements (links)?

Maybe it does have something to do with a combination of the Java and/or CC-Framework version?

Did anybody have any similar problems?
Does anybody have an idea for a (sensible) workaround?
Even if not, do you have any relating ideas?

...could you please add the FIXGRID-definition? Thanks!

In principal there is both some processing from the grid row (selection) and there is some processing from the link (invoke). They should normally not disturb one another, but maybe this somehow is the case in a certain environment...

Regards, Björn

I've attached two screenshots.
As I've said, we're unable exactly pinpoint it.

But we stumbled over a (possible) solution. One person in our team _always_ "suffered" under this unusual behavior. It seems to have been fixed by setting the fixgrid attribute "avoidroundtrips" to "true".

We'll do some further testing trying out that solution.

*bump*

Also wanted to tell you that the semi-fix doesn't seem to work all the time.
("It seems to have been fixed by setting the fixgrid attribute "avoidroundtrips" to "true". ")

It still happens occasionally, they said it fixes the problem like "99%" of the time. But since it still happens, it seems like we're still not at the root of the problem.

Hi,

...I can reproduce a situation like this. It occurs, if the server processing for "onRowSelect" takes a while (I did some Thread.sleep() on server side to reproduce) and when touching the grid the first time...

After touching the grid the first time it is not reproduce-able anymore.

Will check...

Regards, Björn

Hi,

I believe the problem is solved now. I cannot reproduce anymore after apply a fix. So I hope (but strongly expect), that this is your situation as well.

Some background info on the fix: the link is reacting on mouse up, the selection on mouse down. So after pressing the mouse, a communication to the server is triggered - normally blocking all client side eventing, in order to prevent that e.g. the user is keying in text while the client is waiting for the server response.
Now, the blocking of events has certain situations, where it does not block events. It for example says: I always let pass mouse-released events, I always let pass double-click events - even if the event is triggered at a point of time when the client is waiting for the server.
So, this happened all the time: new mouse clicks were blocked, but mouse-ups were let passed - exactly to match situations like the one we are in...
Now in Swing there is an event mouse-clicked and mouse-released. So far we only observed mouse-released (because the mouse-clicked is some kind of derived event). This seems to work in "99%" situations, but it fails in "1%" for whatever reason. This means we let pass the mouse-released but there is no mouse-clicked following after.
So, we corrected in a quite simple way: we also let pass mouse-clicked events...

The fix is part of tomorrow's update (Monday).

I am quite confident that this solves "your" problem: you describe that situation improved when switching to a different AVOIDROUNDTRIPS - which just means that the "risk" of a parallel selection and link processing is decreased drastically.

Thanks for your patience +
Regards, Björn

After our current build goes through QA and gets deployed, we'll actively test it with the new CC version.

Thanks a lot with your help so far, I'll be back when we figure out if this fixed the problem!

A lot of our users said that, while it doesn't seem to be completely fixed, it's a lot better. We'll need to figure out the remaining complaints on a case to case basis, because some of them might be caused by our type of implementation (and some of them might be intended).

So far thanks a lot for your help, again!