General and Desktop

@SantaClade Hi and welcome back Then there must be something else installed on your windows that uses Qt and conflicts with Origin. https://forum.qt.io/topic/118102/origin-cant-find-or-load-the-qt-platform-plugin-windows tried to use listDlls tool to spot the culpit. But seems not to find teh actual reason.

@coutKateM said in I dont know why QString from QlineEdit is not working(: qDebug()<<myLineEdit->displayText(); As @Christian-Ehrlicher has said. If the line above compiles (which I believe you are saying it does), it indicates that you have a member variable named myLineEdit in interface.h, but you assigned to a different variable via QLineEdit *myLineEdit = ....

@mrjj Thanks a lot for the information. I had renamed the file to xlsx. That was the issue. After converting using libreoffice it works and i can fetch information.

@AnneRanch said in Newbie first attempt "No suitable kits found": IMHO there should be a explanation how QTCreator builds an application ( .pro, qmake, make...) and how it interacts with Qtx and QtDesigner. Is it called documentation, isn't it?

Is there any way to do it? Let me know if required any additional information? Thanks

@JonB Thank you for reply and the suggestion. I made the following changes: void MainWindow::resizeEvent(QResizeEvent *event) { QMainWindow::resizeEvent(event); // added void MainWindow::changeEvent(QEvent* e) { QWidget::changeEvent(e); // moved from the end to start of function and tested again but still, when the program is started, the geometry is not of a maximized window. Btw I reimplemented "event" method and printed type/geometry like: bool MainWindow::event(QEvent *event) { QMainWindow::event(event); qDebug() << GetTickCount() << " - " << event->type() << geometry(); } It appears that when the program starts (and showMaximized is used), the 2nd "resize" and 3rd "move" events are responsible for setting geometry to maximized values. [image: vCVFBav.png] Looking at these logs, at program startup, unfortunately there's not a single event that would happen for the first time when the geometry is already updated... Btw my main goal is to use QGraphicsView::centerOn() when program is launched. To make my graphics item appear in the center of the graphics view, which currently does not work like it should because it is applied when geometry of the view is not updated to maximized value. Edit: I made some more tests, calling "windowHandle()->geometry()" returns correct geometry few events before "geometry()" does. It's still not immediate but at least there is a "showToParent" event which happens to output correct geometry when it happens for the first time. So the following workaround could be done: bool MainWindow::event(QEvent *event) { static bool initial_geometry_checked = false; if (!initial_geometry_checked && event->type() == QEvent::ShowToParent) { if (QWindow *window = windowHandle()) { initial_geometry_checked = true; qDebug() << "initial geometry = " << window->geometry(); qDebug() << "incorrect geometry = " << geometry(); } } return QMainWindow::event(event); } which outputs the following when program is started: initial geometry = QRect(1366,23 1600x837) incorrect geometry = QRect(1766,130 800x600)

@JonB yeah actually I knew it... But it was sooo frustrating for me...K was trying so hard to make my app work and it wasn't therefore I tried soo many different paths and commands😁

@Nasser-Ahmed Everything works fine for me (without touching any qtlogging.ini, should that indeed have qt..debug=false, I don't know?), under Ubuntu with all distro-released Qts, I never compile. One thing: add your own qInstallMessageHandler(myMessageOutput) as per https://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler . All qDebug()/qInfo() etc. go via that. Does that even get hit for you? If it does you have some problem with the output; it it does not you have some problem with your qDebug()s etc., such as compiled to do nothing. Another small thing: your Qt include #include statements should all be #include <something-no-slash>, so: #include <QPushButton> #include <QDebug> Using your "s there could be a danger if it picking up something of your own instead of the Qt system one. Correct those as shown, just in case....

@Isidro-Perla What does "block my combobox" mean to you? Disable it? Make it so it only shows the items it has in it and does not allow the user to type in their own item? Something else?

@Loc888 Then what's the problem here? A RectF can be defined by the topLeft point and the bottomRight point of the rectangle. Or you may try QPolygonF::boundingRect().

The methods Start_Processing_1(), Start_Processing_2() and Start_Processing_3() are run in your main thread. Your QThread instances do nothing. Please read and use the docs, the way QThread works is described in detail there. https://doc.qt.io/qt-5/qthread.html In short: either subclass QThread and reimplement run() or use worker object approach

I took the data on multiple lines as it will take time to install different drivers. Thank you.

@BD9a No Qt way, you'll have to look into your OS specific apis and/or install very low level Keyboard hooks, https://docs.microsoft.com/de-de/windows/win32/api/winuser/nf-winuser-setwindowshookexa?redirectedfrom=MSDN

Thanks again @Christian-Ehrlicher, I honestly don't know if I would have spotted that error! I've changed the line to the following: QObject::connect(myControllerClassInstance, &myControllerClass:reloadClass, myControllerClassInstance, [&engine]()void->{reloadMyController(&engine, myPersistentClass1Instance);}, Qt::QueuedConnection); and it now appears to be working! I've launched the application in modeA, and switched back and forth between mode A and B a dozen times without issue. Thanks again!

@Dmitriano said in Why Q_GADGET is not moved?: Sure, 'copy elision' is not applicable, but I asked about 'std::move' (note that it is not the same). Move semantics is there to facilitate copy elision, nothing else. Theoretically QT engine can determine that the only reference to the gadget exists in QML and call move constructor. At least it is not obvious why this is not possible. No it can't and yes, at least for me the reasoning is rather evident. C++ is a compiled language and is subject to static analysis and subsequent (asm) code generation + optimization. QML is neither of these things. How should or even could a dynamic language be "compiled in" asm, when the latter is already compiled into a target binary? (and that's of course assuming that the whole set of tools for such a thing are available in-language, which they aren't) Basically you're asking "why isn't c++ code recompiling itself while running".

Sorry for pick up this theme again, but I just investigated Qt documentation and found that QSaveFile do that functionality. From the documentation: "QSaveFile is an I/O device for writing text and binary files, without losing existing data if the writing operation fails. While writing, the contents will be written to a temporary file, and if no error happened, commit() will move it to the final file. This ensures that no data at the final file is lost in case an error happens while writing, and no partially-written file is ever present at the final location. Always use QSaveFile when saving entire documents to disk." Hm... It will work on OSX (for sandbox application) or I miss something? UPDATE: QSaveFile - didn't work for sandbox application :-(

Thousands is a bit of an exageration, a few hundred was already a big number... on a second thought we agreed it wouldn't be a problem to limit the user to see something like 20-30 widget (of the most simple type) at the same time - while scene can still easily hold one/two hundred widgets. Anyway, if I understand it correctly, you suggest to call something like QWidget::render(myPixMap) on every widget I have and then keep them in sync with the "real" widget if anything happens. I'm gonna try and see if performance is an issue, especially during the switch to "edit mode". Regarding how the app works, imagine a static report with few interactive parts where the user can modify simple pieces of data (which can in turn modify other data displayed and so on, often creating a complex, but finite, chain of updates). A fundamental aspect is that the data displayed and how it is displayed should be completely customizable, since the type, the number of data and their relation/update rules are not known at compile time and have to "programmed" through a very simple interface by the user. Simple example: the user say all his data consists of a single integer. Then it goes to the "edit mode", add a proper widget(s) to display the int (let's say it has a choice between a QLCDNumber and a more complex widget made up of a line edit with a proper mask and a label with a description). It can add 10 widget of the same type displaying the same information and position them where he likes.

@mrjj Thank You ! :)

I solved issue! with updating PyQt5 5.14.1 to 5.15.1.