TreeList seems to freeze on page down in large list

[robmcmullen]

[Trac time 20080206 063011Z] Hitting the page down key when no tree list item is selected results in a freeze. Eventually it comes out of it, but there must be an O(n!^2) search happening somewhere. Looks like it is a problem in the C++; it seems like it can be worked around by selecting on a node before hitting page down.

A gdb traceback shows:

#0  0x00002b651da685ca in wxBaseArrayPtrVoid::Index (this=0x248d160, lItem=0x2adac70, bFromEnd=false) at ../src/common/dynarray.cpp:405
#1  0x00002b6524ca53dd in wxTreeListMainWindow::GetNextSibling () from /usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gizmos.so
#2  0x00002b6524ca54e8 in wxTreeListMainWindow::GetNext () from /usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gizmos.so
#3  0x00002b6524ca56ce in wxTreeListMainWindow::GetNextExpanded () from /usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gizmos.so
#4  0x00002b6524ca7368 in wxTreeListMainWindow::FindItem () from /usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gizmos.so
#5  0x00002b6524cb0861 in wxTreeListMainWindow::OnChar () from /usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gizmos.so
#6  0x00002b651da4cf10 in wxAppConsole::HandleEvent (this=0x10e8780, handler=0x24c9000, func=<error reading variable>, event=@0x7fff8f5b4090)
    at ../src/common/appbase.cpp:320

and looking at the code in wxPython-src-2.8.7.1/src/common/dynarray.cpp shows a confusing set of macros that seem to be used instead of a template. Hard to see which Insert method is actually being called...

Looks like it might be going through the default loop in wxPython-src-2.8.7.1/contrib/gizmos/wxCode/src/treelistctrl.cpp at line 3661?

[robmcmullen]

[Trac time 20080619 001245Z] Might be fixed with later releases of wxPython...

[robmcmullen]

[Trac time 20080207 052210Z] There's definitely a problem in the C++ source. The page up/page down key gets sent to the FindItem method, which pingpongs around for thousands of times before somehow stopping. It then falls through that case statement and eventually lets the scrolled window handle it. I added the following code in wxTreeListMainWindow::OnChar to short-circuit this:

        // <PAGEUP>, <PAGEDOWN> handled by the scrolled window
        case WXK_PAGEDOWN:
        case WXK_PAGEUP:
            event.Skip();
            break;

but note that the correct way to do this would be to figure out what item is highlighted, move up or down a full page, and highlight the new item.

[robmcmullen]

[Trac time 20080207 052605Z] Since the wxTreeListMainWindow is a subclass of scrolled window, there may be a way to do what I want. I stuck some debugging printing in the following version of OnChar:

        // <PAGEUP>, <PAGEDOWN> handled by the scrolled window
        case WXK_PAGEDOWN:
        case WXK_PAGEUP: {
            int start_x = 0;
            int start_y = 0;
            GetViewStart (&start_x, &start_y);

            int client_h = 0;
            int client_w = 0;
            GetClientSize (&client_w, &client_h);
            printf("view: (%d,%d) client: (%d,%d)\
", start_x, start_y, client_w, client_h);
            event.Skip();
            } break;

but what I'm still missing is a way to figure out what index number the currently selected item is. If I could do that, I think I could get it working.