Author Topic: wxAUI  (Read 29878 times)

bwilliams

  • Guest
Re: wxAUI
« Reply #15 on: January 11, 2006, 06:26:17 am »
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

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: wxAUI
« Reply #16 on: January 11, 2006, 06:33:30 am »
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.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

bwilliams

  • Guest
Re: wxAUI
« Reply #17 on: January 11, 2006, 07:17:39 am »
Quote
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

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: wxAUI
« Reply #18 on: January 11, 2006, 07:20:21 am »
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.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: wxAUI
« Reply #19 on: January 11, 2006, 07:57:53 am »
It's not working for me on the first try. I'll work on it again later. :(
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2808
Re: wxAUI
« Reply #20 on: January 11, 2006, 01:58:41 pm »
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

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: wxAUI
« Reply #21 on: January 11, 2006, 02:06:17 pm »
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. 8)
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2808
Re: wxAUI
« Reply #22 on: January 11, 2006, 06:30:40 pm »
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

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: wxAUI
« Reply #23 on: January 11, 2006, 08:42:24 pm »
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.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

bwilliams

  • Guest
Re: wxAUI
« Reply #24 on: January 12, 2006, 07:21:16 am »
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

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2808
Re: wxAUI
« Reply #25 on: January 12, 2006, 06:38:07 pm »
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;
}
// ----------------------------------------------------------------------------


Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: wxAUI
« Reply #26 on: January 12, 2006, 06:56:14 pm »
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());
}
« Last Edit: January 12, 2006, 07:03:10 pm by 280Z28 »
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2808
Re: wxAUI
« Reply #27 on: January 12, 2006, 07:28:49 pm »
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




Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: wxAUI
« Reply #28 on: January 12, 2006, 08:45:16 pm »
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.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: wxAUI
« Reply #29 on: March 01, 2006, 12:52:39 pm »
Hello,

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

Quote
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