So it looks like I was missing the variable statement after this. It works now. Thanks everyone for the help. QList<QObject*> list() const; for (int index=0; index < list.size(); index++) { QObject *test01 = list.value(0)->name(); qDebug() << test01; }

@SpaceToon I might worry at 20,000, but not at 20 :)

@Yash001 said in which container (Qvector or QList) is good to use for insert, delete, and access the last element.: I am adding data point at last position of container, and only accessing the last element of container. So which is better container? It's what we call Last In First Out ( LIFO) queue. So QStack seems an obvious candidate. QStack inherits from QVector.

@RAJ-Dalsaniya Super to hear \o/ Please mark as solved using the Topic Tool button at first post :)

@oblivioncth said in Why does the const Object returned by QList::at() block access to instance methods?: Hey, going above and beyond! Thanks again. You're most welcome! I'm not completely ignorant in the ways of C++ though, I'm not 100% certain, but fairly confident that: Const 1) Ensures the returned value can't be modified, Yep. the use cases of which I'll admit I'm not really privy to. Use case 1: Allow the caller to read the data without creating a copy, AND Make sure the data is read-only If the returned reference is non-const, the caller will be able to directly modify the object's internal memory. This breaks encapsulation. Use case 2: Allow the function to be called in another const function. There's a const and a non-const version of QList::operator[](int): T & operator[](int i) const T & operator[](int i) const Version #1 allows the caller to modify the QList element. However, it cannot be called in a const function -- it will cause the error in your original post. Thus, version #2 is required for use in const functions. I know that its only really useful when dealing with user defined classes and returning by value reference (which is the case in your example) to prevent memory modification if desired. (Acknowledging your typo) Why would it be "only really useful when dealing with user defined classes"? Notice that QList::at() returns a const reference. I do remember seeing something about this being somewhat obsolete in C++ 11 (or was it 17) and forward, though I'm not sure why. Returning const references is defintiely not obsolete. You might be remembering move semantics, which is said to make passing parameters by const-reference obsolete: https://stackoverflow.com/questions/10231349/are-the-days-of-passing-const-stdstring-as-a-parameter-over Qt will not be making this change anytime soon though; this is too disruptive. Const 2) The pointer argument "arg" in that class is for the type "const MyOtherClass", i.e. a pointer to a constant value (value cannot) Yep, myfunc() cannot modify the MyOtherClass object. (In other words, it can only call const methods of the object) Const 3) Marks the pointer "arg" itself as pointer, so that the pointer itself also cannot be modified) Yep. This is not very useful IMHO, but it's part of the language. Const 4) Thanks to you, I now understand this means that the function does not modify the object instance that the function is being called on/from (i.e. cannot manipulate member variables). Great! Next, start thinking about the difference between logical const-ness and physical const-ness: https://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-state Btw I do like a lot of the explanations on that site as they provide a lot of detail and examples, and I had never read the article for const. Agreed

Hi! Thank you very much for your help. I thought and I want to make little steps at first, so I changed my struct: // person.h struct person { int id; QStandardItem* name; QStandardItem* family; } Now I can directly use my members and append them. I do not need write access, but to show my objects directly in QAbstractTableModel is indeed a sexy idea. I am trying around with QModelIndex, club_model->item(), club_model->itemData() and roles, and when I am done with that, maybe I'll try my own model. For now, my question is solved! Regards Gerhard

@Lasith well std::bad_alloc often comes when out of memory. My guess is that <List1[0].size() is always true since you add to it for each loop and hence create an infinite loop. Did you try VRonin code? Update: If you just want list1 in [0] and list2 in[1] why all the loops then?

@kshegunov said in increasing QList<QStringList> contents twice!: if it looks like a duck, swims like a duck, and quacks like a duck Slight thread derail, but I would say the op's question general is answered .

@VRonin a suggest read is a SO post As mentioned earlier aswel, I will use this iterator (first time :p) Thanks for all the help!

I just had a typo in the group ^^ Sorry!

The easy way: get rid of PortalMapItemInfo, store the values in 4 different QStringList and use a QStringListModel The proper way: in HomeController.h add Q_DECLARE_METATYPE(PortalMapItemInfo) http://doc.qt.io/qt-5/qmetatype.html#Q_DECLARE_METATYPE Instead of a List store your data in a 1-column QStandardItemModel and expose it via a Q_PRPERTY

@Mathan-M Ok, then have a look at my code above; that works as expected, what's different to your code?

Thank you for the hints, I think I now have enough information to solve it.

I too was also thinking of full rewrite but i don't have much time for that right now :/ .

@kshegunov said: You're missing the fact that QWidget and its descendants aren't reentrant. Actually, I missed more than that... I completely miss the fact that, when dealing with QWidget or simillar + threads, that exactely when I should have used signal/slot mechanism... I feel dumb about it, but anyway, the Crawler object now crawls using Qt::Concurrent and send a signal with the text to add to the QListWidget, and then a MainWidget's slot is called to create and add the item. Thanks for your help

I see. Thanks @raven-worx @SGaist!

@Chris-Kawa Sorry for getting you into a mistake and for leaving my problem without any further explanation. So, the variable intArray is just a simple Qlist, i forgot to change its name before posting so please, excuse me for that. For index, it looks like index = w * 4, and after that, there is value = qRgba(intArray[index-3], intArray[index-2], intArray[index-1],intArray[index]); I know that if the length of my text is not divisible, it's not gonna work. And here the Qlist come in handy. I can check if this number is divisible by 4 and if yes, the code goes as it is now, but when it's not I wanted to add as many items equal to 0 as I need to make it divisible. Does my explanation makes any sense? I will try try to explain it like that : if (number is divisible by 4) { here comes my algorithm for making this image } else { add as many number as it is needed to make it divisable to qlist and then run the algorithm } But then those error appeared and I don't really know how can I get rid of them :/ But, how could I make it with vectors? Would it be faster or safer than by using Qlist? Thanks a lot for help!

@Chris-Kawa Got it ;)

@micland WOOW!!! Thank you sooo much micland!! It works!!! I tried a code similar to yours but some data were missing. Just needed to do a very tiny modification on your code: qDebug() << key << value.variant().toString(); or directly qDebug() << value.variant().toString(); Except it, it is perfect! Thank you again. @micland said: I have no clue why the qdbusviewer of Qt 5.6 is unable to call the DBus method but the code snippet above is working fine. I hope it is going to change as I intend to use it or the 5.7 version very soon. Cheers again.

@kshegunov There is a reason why I can't use QT Property Binding (It only support predefined Property using Q_PROPERTY script). Please take a look at my topic about Auto Binding 2 ways with Dynamic Property But Binding is an other topic. About "Object's pointers & Memory" I also take an advise from a Pro in C++ & memory management. His solution is implement a Factory Pattern to Create/Delete Object's pointers (also free memory when an instance had no pointer to it.) (I think I'll give it a try)

I'm such a newbie programmer :( I study electronics engineer and I like programming but I don't receive a good foundation in my university and I had to learn a lots of things by myself. Also, I haven't done any OOP for years and I'm new in Qt. Many many thanks!! I will pay more attention to my coding :)

@mrjj Thank you a lot, it works!!!

However I did certainly what you said that was only little part. Thank for your answer, without it I would only find a way around this issue probably. (like 2 parallel QLists) So what works? I make additional QObject with parent "this (list of lists)". Then I make it parent of every QObject I want to delete (QObjects with list and QObjects within lists). I don't change CppOwnership. After that I clear() list and add new QObjects (obsolete QObjects stay accessible as children of that additional QObject). After final emit I delete that QObject with deleteLater(). QPointer isn't necessary here I think. I tried deleteLater in another way of doing things and it crashed, so that is the only way I found. My application deletes QObject and all children with it. With neither crash or leak. QObject * delQObject = new QObject (this); set_parents_list(delQObject ); m_list_of_listQobjects.clear(); for () m_list_of_listQobjects.append(new listQobject); emit m_list_of_listQobjectsChanged(m_list_of_listQobjects()); delQObject->deleteLater(); where: listoflistsofQObjects :: set_parents_list(QObject * parent) { for (int i = m_list_of_listQobjects.count(); i>0; i--) { m_list_of_listQobjects[i-1]->setParent(parent); m_list_of_listQobjects[i-1]->set_parents_list(parent); } } Following function isn't necessary if QObjects already have parent that is deleted (like listofQObjects or some QObject inside it). It's safer to make elements children, because then one doesn't need to call deletes in destructor. listofQObjects :: set_parents_list(QObject * parent) { for (int i = m_list_ofQobjects.count(); i>0; i--) { m_list_ofQobjects[i-1]->setParent(parent); } } I don't know if is it "right way", I even found here somebody uses my earlier version with additional list (but it's unsafe for sure). The best explanation how to manage memory in qt I found here. If there is better way to do so, please share.

Hi, There's usually no need to allocate QList nor QStringList on the heap. Do you have any reasons to do that ?

When using a custom model, the usage is to add specialized methods to your model to add/remove your custom objects. So when you add/remove a Shape you know exactly where they are so you can use beginInsertRow/endInsertRow and the update will happen automatically for you.

Rather than going up-front with building your own GUI for a painting program, I'd recommend taking a look at what is currently existing like Krita or KolourPaint. Painting is a vast subject that can cover many aspects. Just take a look at Qt's examples on the subject. You should also take the time to look at QtQuick for the GUI design part.

@Asperamanca I am actually not sure anymore. I thought that there was an issue regarding the boundingRect() implementation but I have changed my design since then. I will give this another thought.

Well, your model should then return one column and the string list size as row count. Then data should return the appropriate string from the list

It's been solved. "this" pointer was null, thus it was crazy debugging.

Hi, Do you mean move them at the right position ?

Hi, Something's not clear with your code, you return a QQmlListProperty<MyObject> while mMyObjectsList is a QQmlListProperty<MyObject*>. Also why are you calling (&mMyObjects)->values(); and not mMyObjects.values();?

super, thank you! that solved my litttle problem.

@Jeff-Andle If you do not like that cleanup or if it is too hard to decide whether to free the memory you can use one oft these. QSharedData QSharedDataPointer QSharedPointer I have used QSharedDataPointer (but not the others so far), and it seems to work nice.

@Chris-Kawa Thanks for the reply I messed up as you mentioned above . I used your code to make it work. thank you ;) QList<QColor> colors = { QColor::fromRgb(0,102,104,255), QColor::fromRgb(102,102,104,255), QColor::fromRgb(0,0,104,255) }; for(int i = 0; i < colors.size(); ++i) combo->setItemData(i, colors[i], Qt::BackgroundRole);

at funtion gerarRelatorio i swap the qDeleteAll on line down(original position). and it worked. qDebug()<<"Documentos processados para a Tabela de Relatorio"; acessodb::setDataUltimoRelatorio(idEmpresa,idCliente); qDeleteAll(listaDocumentos); listaDocumentos.clear(); delete modelo; return true; I now will upload to my test server, and see what happens. i doesn't care any more about what is causing the problem, i just hope that is solved.

error: invalid application of 'sizeof' to incomplete type 'QStaticAssertFailure<false>' enum {Q_STATIC_ASSERT_PRIVATE_JOIN(q_static_assert_result, __COUNTER__) = sizeof(QStaticAssertFailure<!!(Condition)>)} I have just read that: Values of a registered type can be constructed dynamically via QMetaType::construct() There is an example in the link above. Thanks for your help! I will figure it out, still missing pure c++ knowledge ;)

I couldn't quite believe that this could be an actual bug, so I kept testing. And the result... oh well... I'm truly ashamed... I have included QDataStream in every file... except the one I actually tested. So the solution is: #include <QDataStream> Facepalm Thanks for your tips, I'm now gonna implement what you told me.