General and Desktop

ok, I'll follow your advise; after I'll give you an answer about my trial. Thanks artwaw

For anyone's reference, this was the line I needed to add to my QMainWindow: this->setAttribute(Qt::WA_NoSystemBackground, true);

@mrjj said in promoted widget & custom class ... not work everytime at same manner: Regarding issues You are using paths to your images "/home/C/res/rect_led_blue_on_130.png" That will break as soon as you run app on other computer. Thanks I know these ... and I have qres file in my app ... sorry but some part of code is reused from other one (when not I use qres yet!). For shure I adjust these ... I use only Queuedconnection because is only an advice signal not command one ... so not need these. At these point for sure the problem become from my thread that read the signal from external world ... the connection with extern world is ok ... verified with wireshark .... so the problem is located onto qthread that read the external signal. Thanks a lot for these confirm. regards giorgio

@ranshalit The force_debug_info probably forces to add additional output when crashing. This should help find the location, but it will not cure the problem. Can you pin the problem to one specific timer? That would give you at least a lead where check. In general it sounds like a pointer is being corrupted. Either directly a timer pointer or some other pointer writing randomly all over the place. In most debug versions pointer are initialized with zero and in release versions this is not the case in general. Sometimes people declare pointers somewhere and check them lateron, if they have been assigned already (e.g. by checking for zero). It happens fast to forget an immediate zero initialzation and the problem will pop up nly in release version later on. Sorry, I can give you only such general remarks, which might be known to you already.

@jsulm Ok let me try out. Thank you!

Ok thank you I will try it.

@batcher Check http://doc.qt.io/qt-5/plugins-howto.html

Hope you don't mind but I added your post to my issues Not in the least. Keep us posted, as this might prove pretty useful for me at some point :p

@jsulm I have seen it, as I have posted the code snippet. Fact is, it is taking time for me to understand and connect the whole picture.

@Romaniy173 Hi, Ok i though you animated some widgets inside the QStackedWidget. Then disable painting will also disable seeing the sliding. The QStackWidget has multiple widgets. I call these pages but its actually more correct to say widgets as it do not have to contain other widgets. Anyway, you could use event filer to steal the paint event and then draw rect yourself. Alternatively use the Render function fo reach widget and draw images of the widget.

@bvox123 add QT += quickwidgets to your .pro file. Don't forget to rerun qmake.

Hello Angel! Thank you so much for your help!! I just solved it :) I did exactly what you specified and then I ran mingw32-make install and I got the .dll in the C:\Qt\5.9.1\mingw53_32\plugins\sqldrivers folder. Thank you again! :) Rocio

@meepo1 alternatively to what @jsulm said, you can take the signal of the Deletebutton and connect that to delete slot of the other buttons. //under the assumption your button to delete all buttons is named "deleteButton" void Window1::db(){ for(int i = 0; i < DefN.size(); i++){ QPushButton *bu = new QPushButton(this); if(DefN[i].indexOf(" ") != -1){ nom = DefN[i].replace(DefN[i].indexOf(" "),1,"\n"); bu->setText(nom+"\n"+DefS[i]); }else{ bu->setText(DefN[i]+" "+"\n"+DefS[i]); } bu->setParent(this); bu->setMaximumWidth(121); bu->setMinimumWidth(121); bu->move(140+120*val,140*val); bu->show(); connect(deleteButton, &QPushButton::clicked, bu, &QPushButton::deleteLater); } }

@AleCasta Sorry, but it is unclear what you want to do and when. Are those buttons the rectangles with numbers in the picture? Why do you want to move them? You can just exchange the numbers. If you want to move them: do you use layout to position the buttons?

@canellas I put an example on github is this what you want?

@enmaniac Thanks for sharing your findings.

Hi We tried using a tool to add to the xml .user file but in the end it turn out it was just easier to merge build steps with the tools we normally use for code merging. Since all of use use this tool on a regular basis, it became a non issue very fast as it's far less complicated than resolving code conflicts. ( one click and u are done in most cases) [image: 7HkApU.png] This works pretty well but only if the others have a pro.user that is somewhat similar to the "master" If the others have added their own build steps, a little more care must be taken with the numbering of each step. ( the key) Other option is to use the shared feature http://doc.qt.io/qtcreator/creator-sharing-project-settings.html But we found it was more work removing the unwanted parts (and NOT ruin the structure) and only having the shared part remaining than simply merge the build step area.

AFAIK, that information is not provided by SQLite.

@SGaist Ok, after fiddling around with debugging and testing things, I believe I have solved it. So my thought process was the user inputs an IP Address 123.123.123.123 and before closing the popup numberpad, clicks on the different LineEdits to change the IP Mask 123.15.16.5. That is why I was checking if(num->isVisible()) because then it would close/delete/popup each time a LineEdit is clicked. I was having problems/segmentation faults because after the user clicks "Done" (or presses Enter/Return on the keyboard), the popup is deleted so checking isVisible()) resulted in errors. To fix this, I created a boolean value numVis that is true if the numberpad is visible, and false otherwise. It is this value that I am now checking and everything seems to work just fine. I hope this makes sense. I will go ahead and mark this as solved.

@artwaw That's absolutely not going to work. Widgets shouldn't be moved to other threads. All ui code needs to run in the main thread. @inforathinam Qt's signal/slot connections do (by default) a runtime check at the time of signal emission. If both sender and the receiver live in the same thread then a direct connection is performed i.e. the slot is invoked in the same thread as the signal was emitted in (it's more or less equivalent to a direct function call). In your case that is exactly what's happening since sender and receiver are the same object (MainView). What you want though is to make a queued connection i.e. the slot to be invoked in the main thread, no matter which thread emitted the signal. Since your object is both sender and receiver Qt can't make that deduction automatically, so you need to help it with an extra argument to the connect() call: connect(mainViewInstance, &MainView::signal, mainViewInstance, &MainView::threadEnded, Qt::QueuedConnection); This way the slot will be called in the receiver's thread (I'm assuming MainView instance is a QObject that was created in the main thread).