Hi Jan Thanks for your reply. I've responded to a few things inline below.
On Mon, May 14, 2012 at 7:59 AM, Jan Kundrát <j...@flaska.net> wrote: > > I'd strongly encourage to check your model using ModelTest [1]. The > trouble with Qt models is that any error you make will usually result in > subtle errors or segfaults at a later time. > I'm actually already doing this. It was very useful when developing my model but currently it is not flagging any issues. > Lazy loading can still work, even in this scenario. You're right that > there seems to be a slight asymmetry in the MVC API when dynamically > updating the model; unlike the hasChildren() method, there's nothing > like childrenArrived() signal and you really have to emulate that by > calling beginInsertRows etc. However, these items that you somehow have > to manufacture can easily be created by your model without actually > fetching their real data; that can be deferred to the time the model > gets aksed for them (through data() or any other relevant function in > your scenario). > > Ok, it's good to know that I'm not missing something here. Unfortunately, in my situation, discovering how many new items there might be is the slow part because this involves traversing several linked lists which could have thousands of members. My model is simply storing a pointer to each object it contains, so getting the data is fast but traversing the list can be slow. It does not look like there is a way to "fake out" the model by calling beginInsertRows telling it that I will insert 0 rows. Otherwise, I think I'd need to insert the correct number of rows, and if I'm going to do that then there is no point to lazy loading in my situation. Your suggestion of returning true from hasChildren() would work but I was hoping to avoid the confusing the user. The data that I am displaying with this model/view combo is a tree structure of in memory objects of different types, analogous to a disk file system with directories and different file types. You are right that creating a model that observes the internal state of the application is very tricky. My approach has been to avoid duplicating as much of the data as possible. Therefore, each index in my model is associated with an Item class I wrote which primarily is used to store a pointer to the actual object and a flag for the type of object. My model's data() method then gets the pointer to the real item and, depending on its type, is able to call my application's internal routines to get things like the name, etc. The real problem is that the pointers I am storing are not to QObject based classes, so I have to go to great lengths to prevent dereferencing these pointers once they no longer exist. I think that if we were to rewrite the application now we would store our data in a very different way, but the application itself is 20 years old and we worry that rewriting the way that the internal data is stored would have plenty of unintended consequences. Thanks for your help Adam Light
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
