// class constructor
ClassBrowser::ClassBrowser(wxWindow* parent, NativeParser* np)
: m_NativeParser(np),
m_TreeForPopupMenu(0),
m_pParser(0L),
m_pActiveProject(0),
m_Semaphore(0, 1),
m_pBuilderThread(0)
{
ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("code_completion"));
wxXmlResource::Get()->LoadPanel(this, parent, _T("pnlCB"));
m_Search = XRCCTRL(*this, "cmbSearch", wxComboBox);
if (platform::windows)
m_Search->SetWindowStyle(wxTE_PROCESS_ENTER); // it's a must on windows to catch EVT_TEXT_ENTER
// Subclassed in XRC file, for reference see here: http://wiki.wxwidgets.org/Resource_Files
m_Tree = XRCCTRL(*this, "treeAll", CBTreeCtrl);
m_TreeBottom = XRCCTRL(*this, "treeMembers", CBTreeCtrl);
int filter = cfg->ReadInt(_T("/browser_display_filter"), bdfWorkspace);
XRCCTRL(*this, "cmbView", wxChoice)->SetSelection(filter);
int pos = cfg->ReadInt(_T("/splitter_pos"), 250);
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashPosition(pos, false);
// if the classbrowser is put under the control of a wxFlatNotebook,
// somehow the main panel is like "invisible" :/
// so we force the correct color for the panel here...
XRCCTRL(*this, "MainPanel", wxPanel)->SetBackgroundColour(wxSystemSettings::GetColour(wxSYS_COLOUR_BTNFACE));
}
// class destructor
ClassBrowser::~ClassBrowser()
{
int pos = XRCCTRL(*this, "splitterWin", wxSplitterWindow)->GetSashPosition();
Manager::Get()->GetConfigManager(_T("code_completion"))->Write(_T("/splitter_pos"), pos);
UnlinkParser();
if (m_pBuilderThread)
{
m_Semaphore.Post();
m_pBuilderThread->Delete();
m_pBuilderThread->Wait();
}
}
<SPLITTER_POS int="195" />
This does not work on Win Vista(at the moment).
Is this value refer to the splitter of the top and bottom view?Codein default.conf file.<SPLITTER_POS int="195" />
I will test this on vista, but the ClassBrowser-class reads the splitter position in the constructor and writes it in the destructor.It is written correctly to the configuration file (when C::B is being closed). Thats what I can tell from tests. So it must be related to loading / applying...
Is this value refer to the splitter of the top and bottom view?Yes.Codein default.conf file.<SPLITTER_POS int="195" />
This does not work on Win Vista(at the moment).confirm this bug in XPSP3.
Is this value refer to the splitter of the top and bottom view?Codein default.conf file.<SPLITTER_POS int="195" />
--- tmp/tmprRirMh-meld/classbrowser.cpp
+++ home/jens/codeblocks-build/codeblocks.trunk/src/plugins/codecompletion/classbrowser.cpp
@@ -122,6 +122,7 @@
XRCCTRL(*this, "cmbView", wxChoice)->SetSelection(filter);
int pos = cfg->ReadInt(_T("/splitter_pos"), 250);
+ XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetMinSize(wxSize(-1, 200));
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashPosition(pos, false);
// if the classbrowser is put under the control of a wxFlatNotebook,
@ all with this problem:Tested, but it still didn't work in WinXP. :(
could you please test the following patch ?Code--- tmp/tmprRirMh-meld/classbrowser.cpp
+++ home/jens/codeblocks-build/codeblocks.trunk/src/plugins/codecompletion/classbrowser.cpp
@@ -122,6 +122,7 @@
XRCCTRL(*this, "cmbView", wxChoice)->SetSelection(filter);
int pos = cfg->ReadInt(_T("/splitter_pos"), 250);
+ XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetMinSize(wxSize(-1, 200));
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashPosition(pos, false);
// if the classbrowser is put under the control of a wxFlatNotebook,
The cause for the issue is, that wxWidgets checks if the requested sash position fits inside the windows actual or min-size.
Normally the min-size of the splitter window is the default min size (-1,-1) and the actual size is very small (If I remeber correctly it'S 20 or something like this).
That only happens for the symbols-browser if it is docked inside the management pane, not if it is free-floating.
For me it was enough to set min-height to 200, even if the requested sash-position is greater than 200.
If the min-height is to large, the sash might get hidden, if the management pane is resized.
EDIT:
Until now only tested on linux (debian 64-bit), windows tests will follow.
confirm this.@ all with this problem:Tested, but it still didn't work in WinXP. :(
could you please test the following patch ?Code--- tmp/tmprRirMh-meld/classbrowser.cpp
+++ home/jens/codeblocks-build/codeblocks.trunk/src/plugins/codecompletion/classbrowser.cpp
@@ -122,6 +122,7 @@
XRCCTRL(*this, "cmbView", wxChoice)->SetSelection(filter);
int pos = cfg->ReadInt(_T("/splitter_pos"), 250);
+ XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetMinSize(wxSize(-1, 200));
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashPosition(pos, false);
// if the classbrowser is put under the control of a wxFlatNotebook,
The cause for the issue is, that wxWidgets checks if the requested sash position fits inside the windows actual or min-size.
Normally the min-size of the splitter window is the default min size (-1,-1) and the actual size is very small (If I remeber correctly it'S 20 or something like this).
That only happens for the symbols-browser if it is docked inside the management pane, not if it is free-floating.
For me it was enough to set min-height to 200, even if the requested sash-position is greater than 200.
If the min-height is to large, the sash might get hidden, if the management pane is resized.
EDIT:
Until now only tested on linux (debian 64-bit), windows tests will follow.
I open "default.conf", and can not find a key named "splitterWin".You have to look for "splitter_pos" in the config file. splitterWin is the ID of the control in the XRC file.
int pos = cfg->ReadInt(_T("/splitter_pos"), 250);
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetMinSize(wxSize(-1, 200));
wxSize minSize;
minSize = XRCCTRL(*this, "splitterWin", wxSplitterWindow)->GetMinSize();
pos = XRCCTRL(*this, "splitterWin", wxSplitterWindow)->GetSashPosition();
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashPosition(450, false);
pos = XRCCTRL(*this, "splitterWin", wxSplitterWindow)->GetSashPosition();
In windows, I have debug these code in the constructor of ClassBrowser class:Codeit is quite strange:int pos = cfg->ReadInt(_T("/splitter_pos"), 250);
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetMinSize(wxSize(-1, 200));
wxSize minSize;
minSize = XRCCTRL(*this, "splitterWin", wxSplitterWindow)->GetMinSize();
pos = XRCCTRL(*this, "splitterWin", wxSplitterWindow)->GetSashPosition();
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashPosition(450, false);
pos = XRCCTRL(*this, "splitterWin", wxSplitterWindow)->GetSashPosition();
I try to write the "450", but the next statement, I GetSashPosition, it is "pos=96".....
The cause for the issue is, that wxWidgets checks if the requested sash position fits inside the windows actual or min-size.
Normally the min-size of the splitter window is the default min size (-1,-1) and the actual size is very small (If I remeber correctly it'S 20 or something like this).
That only happens for the symbols-browser if it is docked inside the management pane, not if it is free-floating.
For me it was enough to set min-height to 200, even if the requested sash-position is greater than 200.
If the min-height is to large, the sash might get hidden, if the management pane is resized.
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashGravity(1.0);
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashPosition(0, false);
m_pClassBrowser = new ClassBrowser(Manager::Get()->GetProjectManager()->GetNotebook(), this);
Manager::Get()->GetProjectManager()->GetNotebook()->AddPage(m_pClassBrowser, _("Symbols"));
@jens or MortenI just tested it on linux: and it does not work !
Just a reminder, can you apply this patch to solve the sash bar problem before the next stable C::B release?
Thanks.
Ok, this patch at least works under Windows. :DFor me it works without this patch on windows (xp sp3, wx2.8.10, gcc 4.4)
I tested it on ArchLinux, and it works well!@jens or MortenI just tested it on linux: and it does not work !
Just a reminder, can you apply this patch to solve the sash bar problem before the next stable C::B release?
Thanks.
Don't know why, no time to digg into it deeper at the moment.
So I am against using it at the moment.