Issue 98973 - Events not working in tabelcontrol fields
Summary: Events not working in tabelcontrol fields
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOO300m9
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
Depends on:
Reported: 2009-02-06 13:43 UTC by sos
Modified: 2017-05-20 10:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description sos 2009-02-06 13:43:19 UTC
I tried to put a Mouse Click event on a Textfield (column) in a 
 TableControl ioff aForm. The event is ignored and the macro on the event 
is not called
Puting the Mouse Click Event on the TableControl itself works properly
Comment 1 Mechtilde 2009-07-17 20:47:39 UTC
can you give a click by click description to reproduce the problem?
Comment 2 sos 2009-08-17 14:45:53 UTC
make a simple macro like "hallo world"
open a new form
place a "TableGrid" control in it
click right on a column
chosse "Column" and go te "Events"
put a link to the "Hallo World" macro on mouse clicked or wathever...
close and try the event on mouse clicked
It will NOT work

only a event placed on the WHOLE TableGrid control works !
Comment 3 marc.neumann 2009-08-18 07:36:08 UTC
confirm and set target
Comment 4 Frank Schönheit 2009-08-21 14:31:53 UTC
Note: This never worked ... The code for displaying those events in the property
browser slipped in "by accident", the table control itself does not contain
*any* code to notify those events. And this is the case since the control has
been implemented in the current form, which is more than 10 years ...

Anyway, I think most of those events can be implemented easily (more or less).
Comment 5 sos 2009-08-21 15:01:19 UTC
OK then I was the very fisrtone  who tryed to make a URL in a column 
clickable :-)
Say you have a URL in a column but also a other URL in a other culumn... I know 
there are mouse position listeners.... but thats a lot of codding effort for a 
cummon user ?  
Events on columns could also been handy to avoid "accidental" clicking on a row.
When using OO as a database frondend we found that the current "forms" has to 
few "data controling", therefore we uses now Dialogs and macro's who are called 
from a click on a row(collumn)to post the data to the tables involved
Comment 6 Frank Schönheit 2009-08-24 13:32:12 UTC
fixed in CWS dba32g

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 7 sos 2009-08-24 18:45:34 UTC
Thanks for this quick fix. Now you are working in the TableControl code, may I 
ask for some Conditional formating (backgrounds and fonts) for rows or/and  
columns. ?

Say yes and I fill a issue :-)
Comment 8 Frank Schönheit 2009-08-24 20:05:04 UTC
You're always welcome to file an issue. In this concrete case, I can't give you
hope that this will be implemented equally quickly, however.
Nonetheless, the number of existent issues for a certain area is an indicator
how much attention this area deserves, so by all means: Submit all enhancement
requests you can think of, please!
Comment 9 Frank Schönheit 2009-09-01 22:36:41 UTC
targeting to 3.2, since the fix is part of a CWS aiming for this release
Comment 10 Frank Schönheit 2009-09-05 21:38:52 UTC
fs->oj: please verify in CWS dba32g
Comment 11 ocke.janssen 2009-09-07 09:07:03 UTC
The current fix is not what a user would expect. You have to click twice into a
column before the event will be fired.Therefor we need a new event for the table
control which will be fired when a cell was hit.
Comment 12 ocke.janssen 2009-09-07 09:07:47 UTC
Comment 13 Frank Schönheit 2009-09-07 19:40:52 UTC
okay, we might need to discuss what is needed here. What I implemented is that
the events which are offered in the property browser or a table control column
actually work. This affects all events for all column types, a lot of them
simply were never implemented. That is how I had understood the summary of the

However, the events only work in an *active* editable table cell, which has two

First, if you bind a macro the the "mouse button down" event, and then click
with the mouse into a previously inactive cell, then this won't fire the event.
Only after the cell has been activated, and you click into it, again, then the
event is fired, and the macro is called.

Second, if the control does not allow editing cells, then no events are fired at
all, since the controls used for editing are responsible for firing the events.

In both cases, this might not be expectation conformant.

fs->sos: My question to you is: How exactly does your scenario look like? What
events *exactly* is your application interested in?
Comment 14 sos 2009-09-08 12:02:01 UTC
sos -> Fs

I can follow your opinion exept for the "editable cell" principle.
We need to call a macro based on the information stored in a cell. Like: "open 
a document based on a url" or open a dialog with information stored in some 
tables but with filtering based on the content of the cell. In most of this 
cases we will choose to make this content "non-etitable"
But in view of: "since the controls used for editing are responsible for firing 
the events."
I can live with it, at condition that we can "click" on individual "active 
Comment 15 Frank Schönheit 2009-09-09 07:53:09 UTC
Well, my terminology might have been imprecise, again :)

Actually, there are two kinds of "readonly-ness". If you set up your table or
form to allow no data modification at all, then the current cell in a table will
only have the small dotted frame. If you set up both the form and the table to
allow data modification (which is the default), then the current/active cell
will be presented by a dedicated input control, usually some kind of text input
control. Therein, you can scroll, select (parts of) the text, etc, just as you
could do with any other text input control in any dialog.

Now additionally, you can set up a certain table column to be read-only. In this
case, the input control is present, too, it it does not allow modifications.

The input controls are responsible for the events.

So with this in mind, and reading your response, this should address your usage
scenario - yes?
Comment 16 sos 2009-09-09 08:27:22 UTC
I think so yes, but eating wil be the proofing :-). Please let us known when 
your current work will be available in a snapshot .
Comment 17 Frank Schönheit 2009-09-09 08:34:27 UTC
I expect it to be available in m59, you can also follow this CWS here:

Alternatively, if you're interested in, I could make install sets for Linux
and/or Windows for this CWS available at
for immediate testing.
Comment 18 sos 2009-09-09 09:44:06 UTC
I will test a Windows version 
Comment 19 Frank Schönheit 2009-09-11 09:07:46 UTC
sorry for the delay, building that OOo instset took longer than expected. Please
find it here:
Comment 20 Mechtilde 2009-09-18 18:43:23 UTC
is this issue fixed in dba32g?
Comment 21 Frank Schönheit 2009-09-22 21:06:37 UTC
fs->sos: Did you have a chance to test this in the CWS snapshot, or in m59,
where dba32g was integrated?
Comment 22 Frank Schönheit 2009-09-29 11:39:04 UTC
fs->sos: Ping. Could you please check the current behavior in m59 or m60, and
tell me how this matches what you expected from this issue?
Comment 23 Frank Schönheit 2009-10-07 14:08:17 UTC
fs->sos: Ping.
Comment 24 Frank Schönheit 2009-10-15 11:30:12 UTC
Moving out to later, since it's not really clear whether there's still work
needed here.
Comment 25 sos 2010-03-15 12:38:51 UTC
Sorry i must mised the call from frank last September,

but a event put on a cell of a tablecontrol (eventon a column) still NOT works 
tested on Windows 3.2
Comment 26 Marcus 2017-05-20 10:45:25 UTC
Reset the assignee to the default "".