Well, no, I think you're missing the point - the little things I'm creating are expected to die with the index. They're simply little containers that provide parent/child information, so I don't have to carry them in the model.
Sure, I can create a traversal mechanism (and have, since I can't seem to get a way to insure these items are deleted.) The traversal mechanism can give me paths and I can derive parent-child relationships from the paths. And they're temporary and go away when I'm done with them.
Fineree.
But - why do I have to do a traversal, when Qt is already doing the traversal? I'd rather take advantage of Qt's traversal mechanism, since it's doing it anyway. (And I could, if I could get these little items deleted along with the QModelIndex deletion.)
Well, the indices have to get created and destroyed. What's another 20 bytes or so? Doesn't seem to be adding a lot of weight.For instance, if you have 100 items, the process of showing them in a view involves creation and destruction of few hundred indices. Do you want to create and destroy such information several times a second? Isn't it better to just keep it and use it when appropriate?
(BTW, the behavior you describe is something of a curiosity - I notice I get called a lot of times for the same indices.)
No, I certainly don't need that. All I'm looking to do is give the indexes a little extra information that will help me create proper indexes, subsequently.If the model changes, all its indices should be considered invalid and should be queried for again. If you need to store an index, you should use QPersistentModelIndex and it is the model's job to update all its persistent indices when its state changes.
Anyway. The tradeoff boils down to adding a small amount of complexity to the indices or a larger amount of complexity to the model to achieve the same thing. I'd rather go with the smaller amount of complexity, if I have the choice.
Since I don't have the choice (at least not without modifying the Qt code - which I really don't want to do), I've re-implemented along the lines you've suggested.
Cheers,
rickb





)
Reply With Quote
Bookmarks