General and Desktop

To add to what @6thC said this is not the correct syntax. You're defining a variable of an anonymous enum type. Should be: enum DrawType { LINE_DRAW, RECT_DRAW, ELLIPSE_DRAW, TEXT_DRAW, IMAGE_DRAW }; signals: void newItem(DrawType drawType) const;

@J-Hilk Tks, I will do a test. Btw, I want to know more the root cause of QSerialport did not emit readyRead () signal.

@Thuan_Firelight said in Mouse events starving timer on Mac OS X?: Does that sound something that would cause a performance hit? yes, that sounds like a very reasonable explanation to your issue :)

Please inform readers if you cross-post to other forums: https://stackoverflow.com/questions/60543683/detecting-peak-value-on-realtime-data-stream This is to make sure people don't spend time answering if you already found a solution.

Hi, The canonical way is to use a Dockerfile.

@samdol said in Creating a dynamic library which is linked to Qt5Widgets.dll statically.: so that my application does not require Qt5--.dlls? No, and I'm pretty sure it will crash sooner or later when you use the arrangement above.

@Babs Anytime. Please don't forget to mark the thread as "solved".

@Pl45m4 yes I restrict the movable area with itemChanged virtual function (found this in internet). But to restrict this area it would be good to know the coordinates of boreders of visible part of QGraphicsView. Now I use fixed width of QGraphicsView and the height I get from the QColorDialog (their heights should be almost the same since they are in form layout). But I'm afraid of would that be ok when porting on other operating system (I'm on Windows now but would it be ok on Linux)?

Alright nevermind, finally i understood how connections work and i implemented one properly this time. Thanks for help.

Thanks, everyone. I think I will do this differently. The table view is actually part of a custom editor which is opened on a cell in another table view. I will do validation only when I commit the data as an entire table. Seems like a much cleaner design and more simple to implement.

@jsulm & @mrjj I solved the problem by moving the QProcess outside the function. Thanks for your support here..

@Brynnjolf Take a look at https://doc.qt.io/qt-5/qtglobal.html#qWarning

@Babs said in Program crash when creating sqlite database: I don't understand yet this mechanism may be any one can explain it? Please create a new post with this subject, so not to hijack this thread. Thanks.

@Pl45m4 , @SGaist Now I am trying to make this work with Qt::WidgetShortcut, which does seem like it should be the right approach. However, it does not work correctly at all! Please don't abandon me! Read on... I have a QMainWindow. I design it, and add its toolbar/menu items/shortcuts in Designer. It has 4 widgets inside it. One of them is the QGraphicsScene/View. That has code for, say, Cut. The others do not (at present) have anything for Cut. In the case of a menu item/toolbar/shortcut key Cut I want that to go to the gfx view if it has the focus, else it should be ignored. This really should not be an unusual situation. Some menu items function regardless of which widget has focus (e.g. Save), some depend on which widget has focus (e.g. Cut). I start from the relevant code as generated (mainwindow.py), which includes: self.action_cut = QtWidgets.QAction(MainWindow) self.action_cut.setShortcutContext(QtCore.Qt.WindowShortcut) self.menuEdit.addAction(self.action_cut) self.toolBar.addAction(self.action_cut) self.action_cut.setShortcut(QtWidgets.QApplication.translate("MainWindow", "Ctrl+X", None, -1)) To make this work, I have found I can go: self.action_cut.triggered.connect(self.cut) def cut(self): if QApplication.focusWidget() is self.graphicsView_model: self.model_scene.cutItems() At this point: If I click the toolbar/menu item, regardless of where focus is my cut() is hit. Its code determines whether the gfx widget has focus or not, and correctly works accordingly. If I click Ctrl+X, if the current focus widget absorbs that (e.g. a QLineEdit in some other widget). If not (e.g. on a plain QWidget) it goes via my cut(), and again that checks focus and works correctly. Now I try changing as best I can to make the Cut only apply to my gfx widget. I change/add things like: self.action_cut.setParent(self.graphicsView_model) # OR self.action_cut = QtWidgets.QAction(self.graphicsView_model) self.action_cut.setShortcutContext(QtCore.Qt.WidgetShortcut) # OR self.action_cut.setShortcutContext(QtCore.Qt.WidgetWithChildrenShortcut) At this point: If I click toolbar/menu it still calls my cut() regardless of where focus is. It has not made it so this is only called when self.graphicsView_model has focus. So I will still need to test if QApplication.focusWidget() is self.graphicsView_model. Ctrl+X no longer does anything, regardless of focus. Both of these are no good/not expected. I came across thread starting at https://lists.qt-project.org/pipermail/qt-interest-old/2011-February/031257.html. I think that guy reports my findings trying to use Qt::WidgetShortcut. Summary: So if I install an action on a QWidget I would assume that the actions shortcut is only active if the QWidget has focus, right? But this seems to be broken somehow. . My educated guess would be that this "shortcut context" thing might only work between "dialog and main windows", but not between common QWidgets? In a word: if you expect Qt::WidgetShortcut to work for me, please tell me how?! My case should not be that unusual: some menu items/shortcuts apply regardless of focused window, some do not. If you do not want me to have to use my if QApplication.focusWidget() is self.graphicsView_model-type-dispatching, please tell me how?! I'm exhausted typing this all up.... P.S. And this is only a P.S., I really don't think this is to do with the problem: @SGaist said in Signal/slot vs direct call, and related question: You can associate an action with several widgets. Did you check if sender gives you the information you seek once you add the action to all the widgets you want to use it on ? See the accepted solutuon at https://stackoverflow.com/a/6003452/489865. Note how the approach is still to look at QWidget::hasFocus() to decide which the user was in when trying to invoke the action. If I'm going to do that, my current code will suffice.

Hi i think you want import on your .pro file this QT += core gui multimedia multimediawidgets

Thank you very much @Christian-Ehrlicher and @SGaist for your quick and pertinent answers , I read related bugs description and saw that in 5.12.4 bug had probably been fixed. I was using 5.12.0. I had the possibility to upgrade a little my runtime version for Qt, and installed directly 5.13.0, and tested : it works fine. I mark the subject as closed !