@alpartis yes, indeed. That's the only way I use it. Consider marking this post as "SOLVED".

And just to add to @mrjj, no Makefiles. These kind of files should only exist in the build folder. If you have a duplicate in the project folder, it will drive you crazy.

Hi I do most layouts using Designer and loads mostly data from code. But you dont have to choose one way over the other. The UI forms is converted to code ( see setupUI() ) so sometimes i use Designer to create a layout/setup and then use the code from my code as templates. The main reason we like using UI files is that it allows the non UX developers to do a bit of GUI sometimes as its less involving to drag a new button to a layout than reading heaps of setup code to find right spot. But basically, its more a matter of taste than anything technical . But there are things you need to do from code as designer cannot do it.

@austinp18 Hi The normal route is to use layouts http://doc.qt.io/qt-5/layout.html So the form can adjust to different sizes automatically.

@mostefa said in connecting to database when a form loads using signals and slots: I think that this post is duplicate Strictly speaking it isn't, although it's quite similar.

You might get error is the following statement, since ui is not included ui->MWtextEdit->setText(text) which can be got ridden by adding following syntax in in mainwindow.h #include "ui_mainwindow.h"

One way to do the filtering more cleanly would be to use custom mime-types then in your drop target, you check that mime type and if not whitelisted then refuse the drop. No need for any knowledge of the widget where the item comes from.

Thank you.

@kshegunov well you are not the first :) At all.

Hello, Thanks for taking the time to welcome me into the forums and write about my question. I will then make a placeholder widget, as you suggested, and take it from there. Kind regards.

@KaranBehar Well agile is not different with Qt. Just make sure project is under code revision control and go ahead :)

Thank you for your help

@VRonin Thanks!, this is what I ended up doing in the end, I just wondered if there was a nicer way like StackView.

Hi @exSnake, May be you should try using evaluateJavaScript.

Hi @ealione, you can decide also later how to handle it; I suggest to keep in memory only if you think that the user will use it very often otherwise there's no problem to create/destroy it when is needed

@XADOOO said: ast