wxAUI version 0.9.1 adds:Since they are in 0.9.x there are more to expect when they release 1.0?
* Support for MDI frames
* Gradient captions option
* Active/Inactive panes option
* Fix for screen artifacts/paint problems
* Fix for hiding/showing floated window problem
* Fix for floating pane sizing problem
* Fix for drop position problem when dragging around center pane margins
* Fix for 64-bit compilation
* LF-only text file formatting for source code
0.91 doesn't behave nice in linux. I 'm still looking into it...
EVT_BUTTON(XRCID("btnAuiActiveCaptionColor"), EnvironmentSettingsDlg::OnChooseColor)
EVT_BUTTON(XRCID("btnAuiActiveCaptionGradientColor"), EnvironmentSettingsDlg::OnChooseColor)
EVT_BUTTON(XRCID("btnAuiActiveCaptionTextColor"), EnvironmentSettingsDlg::OnChooseColor)
EVT_BUTTON(XRCID("btnAuiInactiveCaptionColor"), EnvironmentSettingsDlg::OnChooseColor)
EVT_BUTTON(XRCID("btnAuiInaCaptionGradientColor"), EnvironmentSettingsDlg::OnChooseColor)
EVT_BUTTON(XRCID("btnAuiInaCaptionTextColor"), EnvironmentSettingsDlg::OnChooseColor)
patching file src/environmentsettingsdlg.cpp
patching file src/main.cpp
Hunk #1 succeeded at 1228 (offset -1 lines).
patching file src/resources/env_settings.xrc
patching file src/wxAUI/manager.cpp
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file src/wxAUI/manager.cpp.rej
patching file src/wxAUI/manager.h
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file src/wxAUI/manager.h.rej
So it was you Sam, the "nobody" who posted this patch at SF.
Afraid to say it but it doesn't apply to the current SVN HEAD...
(Stripping trailing CRs from patch.)
patching file src/environmentsettingsdlg.cpp
(Stripping trailing CRs from patch.)
patching file src/main.cpp
(Stripping trailing CRs from patch.)
patching file src/resources/env_settings.xrc
(Stripping trailing CRs from patch.)
patching file src/wxAUI/manager.cpp
Hunk #1 FAILED at 18.
Hunk #2 FAILED at 40.
Hunk #3 FAILED at 145.
Hunk #4 FAILED at 156.
Hunk #5 FAILED at 168.
Hunk #6 FAILED at 184.
Hunk #7 FAILED at 193.
Hunk #8 FAILED at 213.
Hunk #9 FAILED at 260.
Hunk #10 FAILED at 268.
Hunk #11 FAILED at 293.
Hunk #12 FAILED at 351.
Hunk #13 FAILED at 381.
Hunk #14 FAILED at 395.
Hunk #15 FAILED at 415.
Hunk #16 FAILED at 492.
Hunk #17 FAILED at 602.
Hunk #18 FAILED at 647.
Hunk #19 FAILED at 742.
Hunk #20 FAILED at 922.
Hunk #21 FAILED at 957.
Hunk #22 FAILED at 1024.
Hunk #23 FAILED at 1038.
Hunk #24 FAILED at 1072.
Hunk #25 FAILED at 1100.
Hunk #26 FAILED at 1625.
Hunk #27 FAILED at 1651.
Hunk #28 FAILED at 1676.
Hunk #29 FAILED at 2303.
Hunk #30 FAILED at 2359.
Hunk #31 FAILED at 2449.
Hunk #32 FAILED at 2503.
Hunk #33 FAILED at 2591.
Hunk #34 FAILED at 2751.
Hunk #35 FAILED at 2800.
Hunk #36 FAILED at 2850.
Hunk #37 FAILED at 2868.
Hunk #38 FAILED at 2990.
Hunk #39 FAILED at 3084.
Hunk #40 FAILED at 3216.
Hunk #41 FAILED at 3254.
Hunk #42 FAILED at 3281.
Hunk #43 FAILED at 3307.
Hunk #44 FAILED at 3348.
Hunk #45 FAILED at 3410.
Hunk #46 FAILED at 3483.
Hunk #47 FAILED at 3529.
Hunk #48 FAILED at 3605.
Hunk #49 FAILED at 3947.
49 out of 49 hunks FAILED -- saving rejects to file src/wxAUI/manager.cpp.rej
(Stripping trailing CRs from patch.)
patching file src/wxAUI/manager.h
Hunk #1 FAILED at 26.
Hunk #2 FAILED at 45.
Hunk #3 FAILED at 81.
Hunk #4 FAILED at 142.
Hunk #5 FAILED at 163.
Hunk #6 FAILED at 208.
Hunk #7 FAILED at 294.
Hunk #8 FAILED at 328.
Hunk #9 FAILED at 413.
Hunk #10 FAILED at 445.
Hunk #11 FAILED at 551.
Hunk #12 FAILED at 597.
12 out of 12 hunks FAILED -- saving rejects to file src/wxAUI/manager.h.rej
# fix line endings
perl -pi -e 's/\r\n/\n/;' *.c *.h *.patch testing/*.c testing/*.h testing/Makefile
# prepare the checkout
perl -pi -e 's/\$Id[^\$]+\$/\$Id\$/;' *.c *.h testing/*.c testing/*.h testing/Makefile
# apply the patch
patch -p0 -N < library.patch
Only TortoiseSVN can apply patches created by TortoiseSVN :(I don't use TortoiseSVN but the plain svn can create patches (i.e. diff-files) that can be applied using the linux/unix tool 'patch'. Just run 'svn diff <the file you want to create the patch from> > yourpatchfile' (This produces a normal svn diff and saves the output in the file named 'yourpatchfile' - works on linux but should work also on Windows). To apply the patch just run 'patch -p yourpatchfile' (iirc).
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 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'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
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??
// ----------------------------------------------------------------------------
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;
}
// ----------------------------------------------------------------------------
//static wxWindow* FindWindowById(long id, wxWindow* parent = NULL)
wxWindow window = wxWindow::FindWindowById(m_frameid);
if ( window )
window->RemoveEventHandler(this);
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());
}
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
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.
Hello,
Just for info. It seems that soon wxAUI version 0.9.2 will be available :). From bwilliams (http://www.kirix.com/en/community/forums/viewtopic.php?t=97):QuoteNext 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
Hello,
Just for info. It seems that soon wxAUI version 0.9.2 will be available :). From bwilliams (http://www.kirix.com/en/community/forums/viewtopic.php?t=97):QuoteNext 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
It is finally out. :D
http://www.kirix.com/en/community/opensource/wxaui/about_wxaui.html
Check this out.
"wxAUI now supports wxMac!"