Mouse events for different tables: How to handle?

[robgeek]

Hello!

I'm making a program which has many tables, lets say for this post, two tables. So, with the table_1 i want to capture mouse events and do something when left button is pressed and other thing when right button is pressed. To do that i created a class called Table derived from QTableWidget and reimplemented mousepressevent(). I created using Desing a table and promoted it to Table. For this table, everything is working fine.

But now, i want to do the same thing with table_2, but i don't know how to select the context, when i click on the table_1 do this, when i click in the table_2, do that. I wonder if i have to create another class, like Table2, rewrite mousepressevent() and promote table_2 to Table2.

What do you think? What is the best way for doing that?

[Zandru]

your context (the widget table_1 or table_2) should be in the "this" pointer in your reimplementation of mousePressEvent()

[robgeek]

So, i have to promote each table to different classes in which i have different mousePressEvent() implementation?
For instance:

table_1 promoted to Table1(here i have an mousePressEvent())
table_2 promoted to Table2(here i have an mousePressEvent())
table_3 promoted to Table3(here i have an mousePressEvent())

table_1 promoted to Table1(here i have an mousePressEvent())
table_2 promoted to Table2(here i have an mousePressEvent())
table_3 promoted to Table3(here i have an mousePressEvent())

To copy to clipboard, switch view to plain text mode 

Here my basic implementation of mousePressEvent().

void Table::mousePressEvent(QMouseEvent *event) {
    QTableWidget::mousePressEvent( event );
 
    if(event->button( ) == Qt::LeftButton) {
        this->currentRow( );
        this->currentColumn( );
        // Do something with this table.
        //"this" is the table made with Desing promoted to Table.
    }
    else if(event->button( ) == Qt::RightButton) {
        this->currentRow( );
        this->currentColumn( );
        // Do other thing with this table.
    }
 
    // And if i click on other table?
}

void Table::mousePressEvent(QMouseEvent *event) {
    QTableWidget::mousePressEvent( event );

    if(event->button( ) == Qt::LeftButton) {
        this->currentRow( );
        this->currentColumn( );
        // Do something with this table.
        //"this" is the table made with Desing promoted to Table.
    }
    else if(event->button( ) == Qt::RightButton) {
        this->currentRow( );
        this->currentColumn( );
        // Do other thing with this table.
    }

    // And if i click on other table?
}

To copy to clipboard, switch view to plain text mode 

[anda_skoa]

If the mouse handling is different, then yes, a second class will give you the best separation.

Cheers,
_

[Zandru]

now, you only need 1 class. your ONE code for mousepressevent can then check if the "this" object is table1 or table2 and do different things for these cases

[robgeek]

If the mouse handling is different, then yes, a second class will give you the best separation.

Cheers,
_

In my real case, i have four tables, each one with different behavior when i click on them, then the best way for doing that is creating four classes, like my example in post #3?

[anda_skoa]

I would say so yes.
Alternatively four differen event filter classes.

Or one view subclass that delegates click handling to an object of special purpose class and four implementatiin of that interface.

Or one view subclass that emits a signal and handling the signal of the different views in different slots.

Zandru is of course right that in theory that can also be achieved by somehow identifying each instance of the same class, e.g. via the objectName or something set from outside, but this can get unwieldy quite soon.

Cheers,
_

[d_stranz]

In cases like this, I will implement a single class and add an enum or some other type of flag I set when I create the instance that allows my code to distinguish which version of the class a given instance is. If all you need to do is change some small bit of behavior, then using this approach with a switch() based on the enum value is often the easiest. I like this style because it puts all the code in the same place instead of scattering it over multiple classes or methods.

On the other hand, if there are many differences between versions of the widget, then doing as anda_skoa suggests is cleaner and more maintainable.