General and Desktop

@jsulm Sorry to have put it here, this code was meant to be posted for FlowLayout Qs : For this Q

@jsulm In mainThread I have connect like this: connect(this, &MainWindow::getId, simpleObject , &simpleClass::getHandle); EDIT And I send to simpleObject signal getId(). Of course I did: simpleObject->moveToThread(thread);

@jsulm OP's code outputs a message to say if file opened or not. I cannot believe OP would complain about later failure to write to file if the message had indicated the open had failed, and would have told us so, surely....

@thierryhenry14 Signals/slots across threads use copies of parameters, even if you specify the parameters as references. So, it should be safe, as a copy of your shared pointer will be created as soon as you emit the signal.

Thank you so much, this saved my life! Ive been trying to figure this out for my classes final project and dont know why I struggled with this so much. It was so obvious lmaoo.

@mrjj said in How to open MainWindow with signal: @mpergand did we miss a new in the code ? Yes indeed :)

@JonB Much appreciate. I've solved the problem under your instruction. Here are the test results: I've found that under the Win 10 you can't directly use .qrc file(s) every time it will feedback Could not create pixmap from But here is the point: this method work just fine under the win 8 or win7 with Python 3.6 or maybe below(I've only tested on the other two computers: one with win 8.1 and python 3.6.2 another is win 7 with python 3.5.0. My friend, if you found the issue happened in another version of Python or windows system please let me know) I DO NOT KNOW WHY there be differences. But under the win 10 and python 3.9.6(my current development environment), this happens! here's what I do: By turning the .qrc file to .py and importing the file to my main code. step 1: Win + R turn on the CMD and locate the .qrc address. cd PATH step 2: use the code below in CMD. pyrcc5 filename.qrc -o filename.py step 3: add a line at the beginning in your main python code: import filename As for your mentioned method number 2. it works fine for all scenarios. Of course, we can use the img resources directly. BUT, if the project involved enormous forms, Imgs, icons, pictures. I do recommend you use the .ui directly by the loadUI() method.

Thank you. Signals and solts are useful by the way.

RenderBin::draw() is a OSG function so I don't see what Qt can do against it. I would guess you also get the warning in a native non-Qt environment.

@Helios said in Batch data prefetch in QAbstractItemModel: if I could know when the view is about to make a bunch of data() calls You can't but there is a way around it, albeit not pretty. When data or multiData requires the decoration add this request to a QQueue then have slot connected to a QTimer that will check whether there is stuff in the queue and process it all at once.

@SGaist Thank you;

Making the for counter static will definitely make the behaviour go wrong if the function is called more than once. If it is the case that there are "compiler warnings that you eliminate by making i static in your for loop" I too would like to see the original warnings. Separately there are incorrect assumptions about what you can afford to do to i in the loop. For example, in a loop which limits it to i < xml_edit.length() one cannot afford to go: i++; if (xml_edit[i] != '/') and other similar cases.

@AnneRanch Usually StatusBar is part of QMainWindow. But you can add one to a layout: auto statusBar=new QStatusBar; auto progressBar=new QProgressBar; statusBar->addPermanentWidget(progressBar); statusBar->showMessage("Hello"); layout->addWidget(statusBar);

You're welcome ! Since you have it working now, please mark the thread as solved using the "Topic Tools" button or the three dotted menu beside the answer you deem correct so that other forum users may know a solution has been found :-)

Did you meant to write QTimer::singleShot(200,this,[&,param](){ fun(param); }); i.e. actually call the fun function from the lambda? If so, lambdas are immutable by default, which means param becomes const when copied by the capture group. You can't then use it as a non const parameter to fun. Couple of ways to fix this: If you don't want to modify str then make it a const parameter i.e. void fun(const QString& str). If you want to modify the original parameter capture it by reference, not by value i.e. [&](){ fun(param); } or explicitly [&param](){ fun(param); } If you want to capture param by copy and modify that copy then you have to make the lambda mutable [=]() mutable { fun(param); } or explicitly [param]() mutable { fun(param); } There's usually no reason to do that, but if you really want to you can.

@Thank-You You already have window = QWindow::fromWinId(hWnd); container = QWidget::createWindowContainer(window, ui->mdiArea); The solution at that stackoverflow link is merely to add window->setFlags(window->flags() | Qt::FramelessWindowHint); I have no idea whether that is relevant to your situation, just saying that is all they are adding.

@Thank-You said in Using QWebkit for windows with mingw: And I found that many websites doesn't considered it as supported version. Web engines are very difficult to maintain because of security requirements. That is why the Qt Project replaced Qt WebKit (which was mostly maintained by the Qt folks) with Qt WebEngine (which is mostly maintained by the Chromium folks). @Konstantin-Tokarev has done a great job making Qt WebKit compatible with recent versions of Qt, but the last update was over 1 year ago. Lots of security vulnerabilities have been discovered in WebKit since then; that is why many websites don't consider it as a supported version. Main purpose of this is to run services like gmail , google docs and other servuces. Which would be good? Qt WebEngine for desktop platforms; Qt WebView for mobile platforms.

@WesLow The problem with your method/variable is that it is too fragile at attempting to correctly keep in sync with what the stacked widget's current page/index actually is. For example, if anything changes s->currentIndex() by whatever means you will not update your variable accordingly. If you really wanted to maintain a variable, a more robust approach would be to look at QStackedWidget's Signals: put a slot on currentChanged(int index) (maybe widgetRemoved(int index) too) and update your variable there. At least that cannot then get "out of sync". But it is still easier to sub-class and add the two methods I showed earlier.