wxAUI

[bwilliams]

Gotcha.  Maybe we should intercept a wxActivateEvent for frame deactivation.  This would then mark any active panes as inactive.  Is that workable?

I'd be interested in your solution, too.

Best,
Ben

[280Z28]

Can we re-write the Init and UnInit functions to use m_frame->Connect() for just the events we want to listen to?

Code::Blocks does that to listen to wxScintilla events.

wxEvtHandler::Disconnect() seems monstrously more powerful and less error prone than PopEventHandler()

If you've tried this and it didn't work, then I'll just leave it be, but I'd be willing to try to rewrite it and see how things go.

[bwilliams]

Can we re-write the Init and UnInit functions to use m_frame->Connect() for just the events we want to listen to?

Code::Blocks does that to listen to wxScintilla events.

wxEvtHandler::Disconnect() seems monstrously more powerful and less error prone than PopEventHandler()

If you've tried this and it didn't work, then I'll just leave it be, but I'd be willing to try to rewrite it and see how things go.

I think that's a great idea.  Would you be willing to post a patch here or on our forums?  I'd love to try it out.  PopEventHandler() is a tricky thing, and can cause problems in more complicated wxWidgets scenarios.

Thanks,
Ben

[280Z28]

It also could cause problems in a situation like this:

wxAUI pushes
wxSomethingElse pushes

wxAUI::UnInit pops, but pops the wxSomethingElse handler. wxAUI is still on the event stack  :shock:

I'll do that and post a patch.

[280Z28]

It's not working for me on the first try. I'll work on it again later.

[Pecan]

I haven't read the code, but I've run into this problem with
two other modules.

wxWindows::RemoveEventHandler() is a much safer way
of removing event handlers than PopEventHandler.

I dont think PopEventHandler should be used in a multi-module
program. How can you know it's the right event handler??

thanks
pecan

[280Z28]

I haven't read the code, but I've run into this problem with
two other modules.

wxWindow::RemoveEventHandler() is a much safer way
of removing event handlers than PopEventHandler.

I dont think PopEventHandler should be used in a multi-module
program. How can you know it's the right event handler??

thanks
pecan

I think that's just what I'm looking for.

[Pecan]

I've noticed that undocked windows are "alway-on-top" so that
it hides the main CB window and editor.

?Is there an option that can make the undocks more friendly?
I hate my editor code hidden. Like a pin/tack/clippy/nail/40 aught?

thanks
pecan

[280Z28]

I've noticed that undocked windows are "alway-on-top" so that
it hides the main CB window and editor.

?Is there an option that can make the undocks more friendly?
I hate my editor code hidden. Like a pin/tack/clippy/nail/40 aught?

thanks
pecan

Then you couldn't find them cause they don't show up on the task bar.

[bwilliams]

I haven't read the code, but I've run into this problem with
two other modules.

wxWindows::RemoveEventHandler() is a much safer way
of removing event handlers than PopEventHandler.

I dont think PopEventHandler should be used in a multi-module
program. How can you know it's the right event handler??

Hi pecan,

Good idea.  We'll use RemoveEventHanlder() from now on.  Works like a charm.

Best,
Ben

[Pecan]

you might also consider the following code. wxWindow::RemoveEventHandler()
depends on a valid window pointer. My experience says that stowed window
pointers become invalid quickly as CB opens/closes/destorys/deletes frames,
panels, list/tree ctrls etc...

I had to use if (winExists(p)) before calling p->RemoveEventHandler(thisorthat)
because "*p" may have disappeared along with its EventHanders.
If so, just do the delete thisorthat.

thanks
pecan

Code

// ----------------------------------------------------------------------------
wxWindow* wxKeyBinder::FindWindowRecursively(const wxWindow* parent, const wxWindow* handle)
// ----------------------------------------------------------------------------
{//+v0.4.4
    if ( parent )
    {
        // see if this is the one we're looking for
        if ( parent == handle )
            return (wxWindow *)parent;

        // It wasn't, so check all its children
        for ( wxWindowList::compatibility_iterator node = parent->GetChildren().GetFirst();
              node;
              node = node->GetNext() )
        {
            // recursively check each child
            wxWindow *win = (wxWindow *)node->GetData();
            wxWindow *retwin = FindWindowRecursively(win, handle);
            if (retwin)
                return retwin;
        }
    }

    // Not found
    return NULL;
}
// ----------------------------------------------------------------------------
wxWindow* wxKeyBinder::winExists(wxWindow *parent)
// ----------------------------------------------------------------------------
{ //+v0.4.4

    if ( !parent )
    {
        return NULL;
    }

    // start at very top of wx's windows
    for ( wxWindowList::compatibility_iterator node = wxTopLevelWindows.GetFirst();
          node;
          node = node->GetNext() )
    {
        // recursively check each window & its children
        wxWindow* win = node->GetData();
        wxWindow* retwin = FindWindowRecursively(win, parent);
        if (retwin)
            return retwin;
    }

    return NULL;
}
// ----------------------------------------------------------------------------

[280Z28]

There are several sections of wxAUI where recursive searching for windows might be good, but I haven't thought through them enough to be sure of myself in saying so. If you can say for sure that the parent window's ID is unique, then you could store the frame's ID and call the following in UnInit():

Code

//static wxWindow* FindWindowById(long id, wxWindow* parent = NULL)

wxWindow window = wxWindow::FindWindowById(m_frameid);
if ( window )
    window->RemoveEventHandler(this);

And your findWindowRecursively function might look like this. It would work right for:

1) Any window with a unique ID.
2) Any child window with a unique ID up to parent's scope.

This is the key. If you can scope your calls or (if it's one of the main frames of the app) know that it's unique, this is good.

Code

wxWindow* FindWindowRecursively(wxWindow* parent, wxWindow* child)
{
    if ( !parent || !child )
        return NULL;
    return wxWindow::FindWindowById(child->GetId(), parent);
}

wxWindow* wxKeyBinder::winExists(wxWindow *parent)
{
    if ( !parent )
        return NULL;
    return wxWindow::FindWindowById(parent->GetId());
}

[Pecan]

When your *pointerToWindow has disappeared, you
cannot use it to do FindWindowById or any any FindXXX
calls to the wxWindow code. It'll get a segfault.

If you have stowd locally the address of the windows/frames
etc, my experience says it is unique. Its like a MSwnd handle.

The window id is unique also, according to the docs, but to
use it requires a valid wxWindow ptr, which, in many CB
situations is not the case. Especially for plugins that have
stowed windowPtrs in a local array.
I have had SO MANY stale window ptrs.

In order to Remove the EvtHandler and delete the instance,
ya gotta do it by wxWindow ptr. If the window is gone,
ya better find out before hand (before using the ptr.)
and just do the delete.

thanks
pecan

[280Z28]

When your *pointerToWindow has disappeared, you
cannot use it to do FindWindowById or any any FindXXX
calls to the wxWindow code. It'll get a segfault.

If you have stowd locally the address of the windows/frames
etc, my experience says it is unique. Its like a MSwnd handle.

The window id is unique also, according to the docs, but to
use it requires a valid wxWindow ptr, which, in many CB
situations is not the case. Especially for plugins that have
stowed windowPtrs in a local array.
I have had SO MANY stale window ptrs.

In order to Remove the EvtHandler and delete the instance,
ya gotta do it by wxWindow ptr. If the window is gone,
ya better find out before hand (before using the ptr.)
and just do the delete.

thanks
pecan

Why don't you just store an array of their IDs, and maybe the ID of a parent? So you can find the parent by ID, and then find children by ID. If you have the ID, it won't crash.

[Michael]

Hello,

Just for info. It seems that soon wxAUI version 0.9.2 will be available . From bwilliams:

Next week I plan to put in a solid week and hopefully get 0.9.2 out by the end of next week. That is an optimistic estimate, because there are a few new features I'd like to code. Normally we prefer to do monthly, but I was distracted by another pressing need.

Best wishes,
Michael