Thanks for the ideas, I got it working like this now: bool myWidget::event(QEvent* e) { if(e->type() == QEvent::Leave) { QPoint view_pos(x(), y()); QPoint view_pos_global = mapToGlobal(view_pos); QPoint mouse_global = QCursor::pos(); if(mouse_global.x() < view_pos_global.x() || mouse_global.x() > view_pos_global.x() + width()) { closeMenu(); } else if(mouse_global.y() < view_pos_global.y() || mouse_global.y() > view_pos_global.y() + height()) { closeMenu(); } } return QWidget::event(e); }

Was able to solve it by outcommenting selectionHandle in the custom keyboard style.qml file.

@jsulm actually, it doesn't work at all, from my quick test I made. I'm not entirely sure why...

need to check Qt classes for system settings and native look and feel, and of adopting those changes for App. Thanks,

No ideas? =(

Put the list widget in a layout. Here's more on layouts in Qt.

@KevinD said in Modal from a modal (Mac): Hi, Don't use these two: box.setModal(true); box.setWindowFlags(box.windowFlags() | Qt::Popup); You're calling QDialog::exec which is for modal-only dialogs, and Qt::Popup isn't for dialogs, leave the window flags be. If you prepare a MWE (the download-and-build type) I can test on Linux (I have no Mac, sorry). Also you might consider filing a bug report if everything else fails. Kind regards.

@Rohith no it's not. You would have to implement your custom QDialog subclass. Which shouldn't be much of an effort.

@p3c0 said: Cast to QObject instead of QQuickItem. That works. :) Thanks.

I got it. Thank you for your help.

Hi @alex_malyu , Thank you for the detailed explanation. It makes more sense now.

Thank you!!

@aney Yeah when meta compiler doesn't run, it all get a bit strange. :) In first post , under it. to the right. is Topic Tools button. It can mark as solved.

Thanks so much for posting this result! This worked for me in QT 5.14.2 @seyed said in Android soft keyboard action button: NOTE: Action button of the Android soft keyboard is same as return button which you can control it in XML layout file with 'imeOptions' attribute. Can you elaborate on this? I'm working on Android and am not seeing the 'Done' button changing as expected, but I do see in the QT Docs: Note: Not all of these values are supported on all platforms. For unsupported values the default key is used instead.

@Coloriez In header file you probably have: class HelpDialog : public QWidget { Q_OBJECT public: HelpDialog(QWidget *parent); // this is declaration of the constructor ~HelpDialog(); .... /// Every function declared and called implicitly or explicitly needs to be implemented. Implementation usually is either provided at the same it was declared at or in cpp file, For example You could replace HelpDialog(QWidget *parent); with HelpDialog(QWidget *parent) {}; This would add implementation which does nothing. But this would be a bad idea in this case. You probably would want constructor which at least initialize parent. For example you could add in cpp file instead: HelpDialog::HelpDialog(QWidget *parent) :QWidget( parent ) { }; I highly recommend re-read C++ book until you understand at least the basics or search for c++ novice forum. Your questions have nothing to do with Qt yet. This is not an offence. But I doubt you will be getting help you need here due to specialization of this forum.

Hi and welcome Do you mean if you can get/use the same "dialog" or more like the concept of how to make something pop up like that?

Hi, You would usually use QDataWidgetMapper for such a use case. There's the related examples that show how to do it. Hope it helps

Hi Thanks for the detailed answer, now the issue solved

@didu You're Welcome :) Happy Coding...

You can't load Qt dlls when you want to simply because they are linked to your program and need to be resolved at startup. That's just how it works. If you were to load Qt dlls when you wanted (e.g. using QLibrary) you would have to also manually resolve addresses of all functions and classes. It's possible but just impractical at this scale. But here are two ideas what you could do: One way would be to split the app in two. First one would be the loader (the dialog) and it would use QProcess to start the main app when it finishes its work. Handy for updating the main app too as it's a separate file. The other idea would be to make your main app a shared library and load it dynamically with QLibrary at the right time. Same benefit as above except an exe and a library instead of two exes.

Can you try to comment the line OpenFile(filename); and use a qDebug there instead, this function could be the problem Thanks