Discussion:
[qooxdoo-devel] Bug in qx.ui.table.Table cellClick event handler?
Fritz Zaucker
2010-02-11 14:17:34 UTC
Permalink
Hi,

the playground example http://bit.ly/9MKu9x shows the following behaviour:

- cellClicks on focused editable cells don't get cellClick event:

- Single click on any cell in column 0 (editable) and you'll see the
debug message "cellClick event" in the console

- Click into this cell again and you won't get an cellClick event

- cellClicks on focused none-editable cells get cellClick events

- Single click twice into a cell in column 1 (not editable) and
you'll get two cellClick events

This seems inconsistent to me. I think in both cases there should be 2
cellClick events.

Or am I missing something?

Cheers,
Fritz
--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch
Alexander Steitz
2010-02-11 15:20:24 UTC
Permalink
Hi Fritz,
Post by Fritz Zaucker
- Single click on any cell in column 0 (editable) and you'll see
the debug message "cellClick event" in the console
- Click into this cell again and you won't get an cellClick event
- cellClicks on focused none-editable cells get cellClick events
- Single click twice into a cell in column 1 (not editable) and
you'll get two cellClick events
This seems inconsistent to me. I think in both cases there should be 2
cellClick events.
Or am I missing something?
I've just tested it with Firefox 3.6 / Linux. I only get one cellclick event
at both columns. So I can not see any differences here :(

Is there any special behaviour I have missed?

cheers,
Alex
Fritz Zaucker
2010-02-11 16:25:44 UTC
Permalink
Hi Alex,

ah, it's even "funnier":

You have to double click one of the cells in column 0 to get into edit mode
and then leave edit mode (by pressing ESC).

After that, a focused cell in either column 0 or 1 doesn't get cellClick
events anymore.

However, if you try the multiple clicks BEFORE ever going into edit mode,
every cell gets every cellClick, no matter if focused or not focused.

Cheers,
Fritz
Post by Alexander Steitz
Hi Fritz,
Post by Fritz Zaucker
- Single click on any cell in column 0 (editable) and you'll see
the debug message "cellClick event" in the console
- Click into this cell again and you won't get an cellClick event
- cellClicks on focused none-editable cells get cellClick events
- Single click twice into a cell in column 1 (not editable) and
you'll get two cellClick events
This seems inconsistent to me. I think in both cases there should be 2
cellClick events.
Or am I missing something?
I've just tested it with Firefox 3.6 / Linux. I only get one cellclick event
at both columns. So I can not see any differences here :(
Is there any special behaviour I have missed?
cheers,
Alex
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
qooxdoo-devel mailing list
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch
Fritz Zaucker
2010-02-12 14:39:08 UTC
Permalink
Bug 3437 Submitted

Cheersm
Fritz
Post by Fritz Zaucker
Hi Alex,
You have to double click one of the cells in column 0 to get into edit mode
and then leave edit mode (by pressing ESC).
After that, a focused cell in either column 0 or 1 doesn't get cellClick
events anymore.
However, if you try the multiple clicks BEFORE ever going into edit mode,
every cell gets every cellClick, no matter if focused or not focused.
Cheers,
Fritz
Post by Alexander Steitz
Hi Fritz,
Post by Fritz Zaucker
- Single click on any cell in column 0 (editable) and you'll see
the debug message "cellClick event" in the console
- Click into this cell again and you won't get an cellClick event
- cellClicks on focused none-editable cells get cellClick events
- Single click twice into a cell in column 1 (not editable) and
you'll get two cellClick events
This seems inconsistent to me. I think in both cases there should be 2
cellClick events.
Or am I missing something?
I've just tested it with Firefox 3.6 / Linux. I only get one cellclick event
at both columns. So I can not see any differences here :(
Is there any special behaviour I have missed?
cheers,
Alex
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
qooxdoo-devel mailing list
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch
Dave Baggett
2010-02-11 15:26:25 UTC
Permalink
I have found a couple problems with tables that I've worked around in my app,
and which may be relevant. I haven't had time to look into these enough to
file proper bugs. FWIW, these may have been fixed already in 1.0, but
perhaps they'll give you and others some useful leads.

- If you make the table widget draggable, you will get ghostbuster symbols
when you click on the headers to sort. The solution is to override the
tablePaneScroller and make it draggable, rather than making the table widget
draggable.

- The focus indicator eats events under IE, causing the context menu event
to never fire. I disable the focus indicator like so, and the events flow
fine:

table.getPaneScroller(0).setShowCellFocusIndicator(false);
table.getDataRowRenderer().setHighlightFocusRow(false);

- I have had to patch table/columnmenu/Button.js to make the column menu
appear the first time the right mouse button is clicked. The patch is to
explicitly add the "appear" listener when the factory method creates the
menu. I don't remember exactly what was going on here, but it seemed like it
was some issue of the listener not getting set up properly in some cases.
This is difficult to reproduce because it has something to do with the
specifics of my table. Without this patch, the context menu appears as a
tiny rectangle with no contents. This has been discussed in the forums
previously, BTW, without resolution.

Hopefully this helps someone.

Dave
--
View this message in context: http://n2.nabble.com/Bug-in-qx-ui-table-Table-cellClick-event-handler-tp4554907p4555316.html
Sent from the qooxdoo mailing list archive at Nabble.com.
Derrell Lipman
2010-05-23 23:49:37 UTC
Permalink
Post by Dave Baggett
I have found a couple problems with tables that I've worked around in my app,
and which may be relevant.
Dave, from this old email I'd saved until I had time to deal with it... Some
of these have been fixed (recently); others need more info if you can
provide it.
Post by Dave Baggett
- If you make the table widget draggable, you will get ghostbuster symbols
when you click on the headers to sort. The solution is to override the
tablePaneScroller and make it draggable, rather than making the table widget
draggable.
Can you provide a playground sample that shows the problem, and also add an
example of your solution?
Post by Dave Baggett
- The focus indicator eats events under IE, causing the context menu event
to never fire. I disable the focus indicator like so, and the events flow
table.getPaneScroller(0).setShowCellFocusIndicator(false);
table.getDataRowRenderer().setHighlightFocusRow(false);
This was fixed this past week.
Post by Dave Baggett
- I have had to patch table/columnmenu/Button.js to make the column menu
appear the first time the right mouse button is clicked. The patch is to
explicitly add the "appear" listener when the factory method creates the
menu. I don't remember exactly what was going on here, but it seemed like it
was some issue of the listener not getting set up properly in some cases.
This is difficult to reproduce because it has something to do with the
specifics of my table. Without this patch, the context menu appears as a
tiny rectangle with no contents. This has been discussed in the forums
previously, BTW, without resolution.
This, too, needs a playground example demonstrating the problem, if you can
figure out how to do so. The snippet you sent me to fix it appears to do
what, in a slightly different place, what the code already does, so I need
an example of the problem occurring to track down what's causing it.

Cheers,

Derrell
Dave Baggett
2010-05-24 18:42:23 UTC
Permalink
The columnmenu bug was in my code, not Qooxdoo. So nevermind about that one.
I'm working on making a playground example to reproduce the ghostbuster bug.

Dave
--
View this message in context: http://qooxdoo.678.n2.nabble.com/Bug-in-qx-ui-table-Table-cellClick-event-handler-tp4554907p5095220.html
Sent from the qooxdoo mailing list archive at Nabble.com.
Derrell Lipman
2010-05-24 18:44:47 UTC
Permalink
Post by Dave Baggett
The columnmenu bug was in my code, not Qooxdoo. So nevermind about that one.
I'm working on making a playground example to reproduce the ghostbuster bug.
Great. Thanks.

Derrell
Dave Baggett
2010-05-24 19:42:02 UTC
Permalink
The other problem on longer occurs. I backed out my code making the table
pane draggable and went back to making the table itself draggable, and it
still works fine (no spurious ghostbusters). So you must have already fixed
this one without realizing it.

Dave
--
View this message in context: http://qooxdoo.678.n2.nabble.com/Bug-in-qx-ui-table-Table-cellClick-event-handler-tp4554907p5095458.html
Sent from the qooxdoo mailing list archive at Nabble.com.
Derrell Lipman
2010-05-24 20:48:32 UTC
Permalink
Post by Dave Baggett
The other problem on longer occurs. I backed out my code making the table
pane draggable and went back to making the table itself draggable, and it
still works fine (no spurious ghostbusters). So you must have already fixed
this one without realizing it.
I like bugs that don't need fixing. :-) Ok, thanks.

Derrell

Loading...