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

List:       kde-devel
Subject:    Re: Clearing a KListView while it's editing an item
From:       Koos Vriezen <koos.vriezen () xs4all ! nl>
Date:       2005-11-02 9:37:33
Message-ID: 20051102093733.GC65708 () xs4all ! nl
[Download RAW message or body]

On 11/2/05, Gábor_Lehel <illissius@gmail.com> wrote:
> On 11/2/05, Koos Vriezen <koos.vriezen@xs4all.nl> wrote:
> > Hi,
> >
> > I noticed that $SUBJECT is causing a crash. Not sure if this is a bug or
> > a 'just don't do that' thing, but I haven't found a way to workaround
> > this. Such as canceling the edit before calling 'clear()' w/o having to
> > schedule this (*), also because the editing is hidden behind the
> > setItemsRenameable()/itemRenamed()/.. API's.
> >
> > (*) eg. I could do a clearFocus() on the listview, but that isn't done
> >     immediately
> >
> > So what can I do to prevent a crash?
> QListView has a bool isRenaming() method (which, incidentally, didn't
> work for me in the case that I tried, so don't know whether it does
> otherwise) -- you could also use KListView's renameLineEdit(), and
> check whether it isVisible().

Yes, but the problem is that if that is the case, I still need to clear
the view. So I actually don't care whether it's in edit mode or not.

Btw, I just commited a workaround based on inspecting the
kdeui/klistview.cpp code (which is of course a hack):

    QFocusEvent fo (QEvent::FocusOut);
    focusOutEvent (&fo);
    clear ();

as that does a KListViewLineEdit::terminate() AFAIGuessed ..

Koos
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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