Let's see if I can be more concise in the body of the message. This doubt comes from an attempt to improve the solution proposed here
In summary, it is about providing a table with a behavior similar to a spreadsheet, that is, that a small mark appears in the current cell so that when drag and drop on it the behavior of the table is different and it is execute an action. In the previously posted link I came to a very cumbersome solution, and I was trying to improve it.
The main improvement is that the mark that has to appear is a widget, and not a drawing of the table itself. This allows me to handle my own signals and functions which makes the code more readable and logical. But the problem is that when I want to start the drag from that point, being actually on the widget and not on the cell, I can't execute a selection.
And my question is if I initiate a drag with the mouse, but when I am hovering over a widget over a cell, is there a way to transmit that mouse movement to the table that is behind the widget.
Update
I don't know if it's the method to follow, but what I'm trying is that the widget on the table (the mark) doesn't accept mouse events and propagates it directly to the parent, using the function ignore()
, but it doesn't seem to work
As I said, this topic comes from behind, with very similar doubts, although not exactly the same .
Although the doubt was resolved in various ways (more or less fortunate), none of them satisfied me. To summarize, what I want is for the table to have a behavior similar to a spreadsheet, so that a small mark appears on the active cell, which can be dragged and in that action, all the cells selected in this way, are changed in some specific way.
I have to say that the answer was practically resolved in the second link. Everything was a matter of adapting the solution proposed by
@eferion
in said link. And, above all, to understand that the correct way of doing things is not to touch the table but rather the event filter, so that the same table will act on keyboard/mouse/etc inputs in one way or another depending on that filter.Otherwise, if I have to modify the table so that it responds differently to events, I condemn it to no use for another occasion or another way to access or manipulate it, and that is definitely bad practice.
Having said all this, I show the solution that I finally consider good:
On the one hand, I create two simple widgets, one will be the restricted selection frame , and the other the mark that will appear at the bottom right of the active cell (they are created in the same file):
file.h
file.cpp
And now the event filter:
myeventfilter.h
myeventfilter.cpp
All that remains is to install the event filter in the viewport() of the table. Here the constructor:
And that's it. In this way the table is not touched. Basically what it does -in this specific case- is to force only cells under the first cell to be selected, and when that selection is finished, an action is executed on them.
The code, while somewhat cumbersome, is pretty self-explanatory.