@hskoglund said in Crushes after deploying!: Hi, googling finds many with the same problem, for example here Just guessing, but perhaps you could try some of the suggestions in there... Thanks for the link. It seems this issue doesn't even solved in Stack Overflow :( Any way, I did some of the suggestions mentioned in it. Installed all redistributable package of x86 (cuz I built my app using Qt mingw53_32) for 2012 - 2013 - 2015 - 2017 (I tested my app after each vcredist) Installed all redistributable package of x64 for 2012 - 2013 - 2015 - 2017 (I tested my app after each vcredist) Nothing changed still see my app crashes without any logical reason! Now I'm very sad because I can run my app only if I installed Qt on my machine which is impractical solution for deploying my app.

As said asserts are not intended to filter out user data, they are there to catch programming errors. If your user can pass you incorrect data, then it's the developer's job to sanitize it and if needed show error messages and handle the error. If the developer's not done his/hers job properly, then it should trip an assertion which is to show that the situation should be fixed. This is not a way to "slap developer's ego" but to catch their misses.

No, it doesn't. The QLayoutItem is not the parent of the widget, it is not a QObject. That's not its job.

Because you didn't ask a question. Use the button to "Ask as question" and then you'll have the "Mark as solved" that should appear.

Hi, You should put that QGridLayout inside a widget that you set on the QScrollArea. See QScrollArea::setWidget

@AthanD actually IMO i believe the grid layout is the most complicated one offered by Qt :) All the others are pretty much straight forward. But since you anyway want to display them in a grid it's your way to go ;)

No, that's the native OS X menu so you can't modify it. Again: use the Info.plist file, it's also explained in QMenuBar's documentation

Hello @JKSH thanks for your response, I already solved the issue, the problem was in qml.qrc file, i just have to edit and update the file list with new icon images, then rebuild the project again.

You're welcome ! Good to know :) Since we know now that it's working, please update the thread title prepending [solved] so other forum users may know a solution has been found :)

@Jessica you're welcomed. Please don't forget to mark the post as solved.

That's normal, the PATH you modify in your terminal in not used by Finder. Take a look at this thread Might help. In any case, you should rather go to the Run part of the Project panel, there you can add these variables for your project so you won't be interfering with others.

Hello guys Thanks a lot for the answers. Your replies got me thinking and I recalled how includes can mess things up. I removed a couple of the include files in some of my header files that turned out to be unnecessary. After removing all the header files while still being able to compile then the program was running again perfectly. Regards Sebastian Aslund

@SGaist ok. thanks

Inside the QTableWidget, I'm guessing I'll have ~100 of my custom widgets at most. In other use cases (i.e. not in the QTableWidget, but in static layouts), I've had up to 4000 of these widgets, with a few hundred being active (i.e. actively refreshing their data from the backend) at the same time, without any serious performance issues, so I know it scales relatively well. Also, to elaborate on the solution I offered above: cloning the custom widget proved difficult, because it has a lot of properties (I simplified the problem, the "custom widget" is actually a family of different widgets to fit different data), and because copying Qt objects is not trivial (see http://doc.qt.io/qt-5/object.html#identity-vs-value). What I ended up doing was write a ContainerWidget to go along the GridWidget. The ContainerWidget has a layout with no margins and is used to display another widget through a setContainedWidget() method. I also added a cloneAndPassContainedWidget() method that does what you'd expect: it returns a new ContainerWidget and gives it ownership of the contained widget. Obviously, after calling the method the original ContainerWidget becomes useless, but the method is called precisely because the original ContainerWidget is set to be destroyed, so that's not a problem. I can now use my GridWidget to display any kind of widgets, it's pretty neat! (I wrote "widget" too many times!) I realize the "proper" way would have been to write a model, views, and delegates, but that would have required a lot more work. EDIT: Here's my updated solution: https://gist.github.com/anonymous/a3b2d7e61c6b3e11742c