'Re: [PyKDE] QAbstractItemView Question'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyKDE] QAbstractItemView Question
From:       Matt Chambers <chambers () imageworks ! com>
Date:       2006-11-20 20:05:05
Message-ID: 45620A71.4020309 () imageworks ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

Andreas Pakulat wrote:
> On 20.11.06 10:51:05, Matt Chambers wrote:
>   
>> Andreas Pakulat wrotee
>>     
>>>> I can detect if one of these elements is not in the new ElementTree, but, how 
>>>> do I get the info needed
>>>> to call beginRemoveRows( QModelIndex parent, int row, int col).  I can get 
>>>> the row,col no problem,
>>>> but how can I get the deleted items parent QModelIndex?
>>>>    
>>>>         
>>> Well, you have to have some mapping from Element back to a proper index,
>>> i.e. you need a way to get the index for an Element in the tree. Then
>>> you can call parent() on that index.
>>>       
>> I remember reading something about how the indexes are temporary.  I was under 
>> the impression
>> that they would go away and be re-created as needed?
>>     
>
> Yes and no. Yes the indexes are not meant to be "stored away", but they
> are cached by Qt's view classes.
>
> What I meant to say, if you implement a function that removes elements
> from your tree and doesn't take a QModelIndex to the parent of these
> indexes (like the removeRows() function does) then you need a way to
> calculate the index for this parent element. I guess the
> element-to-be-removed has a function to retrieve the parent, so you can
> calculate the row+col for that element too, if you can do it for the
> to-be-removed-element. Then to get the parent index of the parent
> element do the same. 
>
> Andreas
>   

Ahh, Ok, I got it thanks.  Working like a charm now.  Thanks!

[Attachment #5 (text/html)]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andreas Pakulat wrote:
<blockquote cite="mid20061120194417.GB28537@morpheus.apaku.dnsalias.org"
 type="cite">
  <pre wrap="">On 20.11.06 10:51:05, Matt Chambers wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Andreas Pakulat wrotee
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">I can detect if one of these elements is not in the new ElementTree, but, how 
do I get the info needed
to call beginRemoveRows( QModelIndex parent, int row, int col).  I can get 
the row,col no problem,
but how can I get the deleted items parent QModelIndex?

        </pre>
      </blockquote>
      <pre wrap="">Well, you have to have some mapping from Element back to a proper index,
i.e. you need a way to get the index for an Element in the tree. Then
you can call parent() on that index.
      </pre>
    </blockquote>
    <pre wrap="">I remember reading something about how the indexes are temporary.  I was under 
the impression
that they would go away and be re-created as needed?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes and no. Yes the indexes are not meant to be "stored away", but they
are cached by Qt's view classes.

What I meant to say, if you implement a function that removes elements
from your tree and doesn't take a QModelIndex to the parent of these
indexes (like the removeRows() function does) then you need a way to
calculate the index for this parent element. I guess the
element-to-be-removed has a function to retrieve the parent, so you can
calculate the row+col for that element too, if you can do it for the
to-be-removed-element. Then to get the parent index of the parent
element do the same. 

Andreas
  </pre>
</blockquote>
<br>
Ahh, Ok, I got it thanks.&nbsp; Working like a charm now.&nbsp; Thanks!<br>
<br>
</body>
</html>

_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

[prev in list] [next in list] [prev in thread] [next in thread] 