PDA

View Full Version : Event Filter doesnt work on Drop Event



DNW
24th October 2015, 20:56
Hello Forum,

I had a QPlainTextEdit and I wanted to change the Drop behavior. When dropped a file with a certain ending instead of pasting the name of the files location, the file should be loaded and the content pasted into the editor.
I tried to avoid subclassing the QPlainTextEdit and installed an eventfilter in my MainWindow that should take care of the editors DropEvents. But this didnt work and dispite of receiving a lot of events (MouseMove, Enter, Leave, etc.) I could not receive a Drop Event.

So I subclassed the PlainTextEdit and everything worked fine. But the Question ist still bothering me. So I played around with it.

I have this Test-EventFilter in my Mainwindow.cpp



bool MainWindow::eventFilter(QObject *obj, QEvent *event)
{
if(obj == ui->plainTextEditGCode){
if(event->type() == QEvent::Drop){
qDebug()<<"Drop Event Filterd in MainWindow class";
return true;
}else{
qDebug()<<"Some other Event Filterd in MainWindow class";
}
}
return false;
}


It is set in the MainWindows constructor

ui->plainTextEditGCode->installEventFilter(this);

In the editors class (inherits QPlainTextEdit) I implemented the DropEvent method



void CodeEditor::dropEvent(QDropEvent *event)
void CodeEditor::dropEvent(QDropEvent *event)
{
qDebug()<<"Drop Event in CodeEditor class";
QPlainTextEdit::dropEvent(event); //seems to be necessary to call baseclass method to make it work poperly
if(event->mimeData()->hasUrls()){
//here the file loading stuff is done
}
}


So when I run this code, and drop a file in the editor I get a debug output like this:



Some other Event Filterd in MainWindow class
Some other Event Filterd in MainWindow class
Some other Event Filterd in MainWindow class
Drop Event in CodeEditor class
Some other Event Filterd in MainWindow class


So apparently the event filter seems to work (receives events) but not for DropEvents. Is there anything special about them that makes them behave differently?

Greetings

DNW

anda_skoa
24th October 2015, 22:25
What could happen is that the drop event is not actually sent to the plain text edit but its viewport widget.

You could check by installing the event filter on ui->plainTextEditGCode->viewport()

Cheers,
_

DNW
25th October 2015, 02:30
Thank you, that was it.

I expanded my EventFilter and installed it in the editors viewport, too.



bool MainWindow::eventFilter(QObject *obj, QEvent *event)
{
if(obj == ui->plainTextEditGCode->viewport()){
if(event->type() == QEvent::Drop){
qDebug()<<"Drop Event filterd from Viewport in MainWindow class";
return true;
}else{
qDebug()<<"Some other Event filterd from Viewport in MainWindow class";
}

}

if(obj == ui->plainTextEditGCode){
if(event->type() == QEvent::Drop){
qDebug()<<"Drop Event filterd in MainWindow class";
return true;
}else{
qDebug()<<"Some other Event filterd in MainWindow class";
}
}
return false;
}


Now my debug output looks like this:



Some other Event filterd from Viewport in MainWindow class
Drop Event Filterd from Viewport in MainWindow class
Some other Event filterd in MainWindow class
Some other Event filterd in MainWindow class


It seems like there a some events that are transfered to the editors viewport instead of the editor. But I am still a bit wondering why I can hande the Event in the subclass then. So it feels like an inconsitancy in the interface. The Dropevent is somehow part of the class but an EventFilter on the entire class is not reaching it. So maybe the event in the viewport is triggerd and it calls the editors event function without using the part of the event system that is handeling the filters. Am I right?

@Mods: can I changes the threads title to add a [SOLVED] in front of it?

anda_skoa
25th October 2015, 07:55
So maybe the event in the viewport is triggerd and it calls the editors event function without using the part of the event system that is handeling the filters. Am I right?

Easy enough to check :)

http://code.woboq.org/qt5/qtbase/src/widgets/widgets/qabstractscrollarea.cpp.html#_ZN19QAbstractScrollA rea11setViewportEP7QWidget

The scroll area sets an event filter on its viewport.

Btw, in your case subclassing the plain text edit is probably the more robust way. Drop events are usually processed by the widget the drop occurs on.

Cheers,
_