Issue 98973

can you give a click by click description to reproduce the problem?

OK:
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 !

confirm and set target

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).

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

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:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba32g

@fs:
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 :-)
 

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!

targeting to 3.2, since the fix is part of a CWS aiming for this release

fs->oj: please verify in CWS dba32g

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.

.

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
issue.

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

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?

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 
cells" 

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?

I think so yes, but eating wil be the proofing :-). Please let us known when 
your current work will be available in a snapshot .

I expect it to be available in m59, you can also follow this CWS here:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba32g.

Alternatively, if you're interested in, I could make install sets for Linux
and/or Windows for this CWS available at ftp://qa-upload.services.openoffice.org
for immediate testing.

I will test a Windows version 
Thanks

sorry for the delay, building that OOo instset took longer than expected. Please
find it here: ftp://qa-upload.services.openoffice.org/dba32g/

is this issue fixed in dba32g?

fs->sos: Did you have a chance to test this in the CWS snapshot, or in m59,
where dba32g was integrated?

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?

fs->sos: Ping.

Moving out to later, since it's not really clear whether there's still work
needed here.

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

Reset the assignee to the default "issues@openoffice.apache.org".