See the screen shot below.
I drag the splitter bar(make the top view a litter larger), but this distance will be reset after CB restarted(This is quite a bit annoying :(). So, My question is: Does this value be saved correctly in the default.conf file?
Some code maybe here:
// 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();
}
}
[attachment deleted by admin]
For me (debian 64-bit) it is the same as it was when closing C::B.
I don't know where and when it is saved (the layout-manager does not ask), but it is saved.
This does not work on Win Vista(at the moment).
Is this value refer to the splitter of the top and bottom view?
<SPLITTER_POS int="195" /> in default.conf file.
Quote from: ollydbg on January 16, 2010, 05:14:59 PM
This does not work on Win Vista(at the moment).
Is this value refer to the splitter of the top and bottom view?
<SPLITTER_POS int="195" /> in default.conf file.
I will test this on vista, but the ClassBrowser-class reads the splitter position in the constructor and writes it in the destructor.
Quote from: jens on January 16, 2010, 06:05:18 PM
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...
Quote from: ollydbg on January 16, 2010, 05:14:59 PM
Is this value refer to the splitter of the top and bottom view?
<SPLITTER_POS int="195" /> in default.conf file.
Yes.
I have the same problem
Ubuntu 9.10
C::B - svn6088
Quote from: ollydbg on January 16, 2010, 05:14:59 PM
This does not work on Win Vista(at the moment).
Is this value refer to the splitter of the top and bottom view?
<SPLITTER_POS int="195" /> in default.conf file.
confirm this bug in XPSP3.
Works on Vista too (for me).
More tests will follow.
I get the expected behavior (position saved and correctly restored) with build 6088 on Fedora 12.
I'll try tomorrow with my XP SP3.
I just found out why it works for some users and not for others.
It works for me, if the symbols browser is displayed as free-floating window, but does not work, if it is docked into the management pane.
I will look into it.
On my XP 32bits SP3, I get the correct behavior... (svn build 6080)
@ all with this problem:
could you please test the following patch ?
--- 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.
Quote from: jens on January 18, 2010, 07:24:51 AM
@ all with this problem:
could you please test the following patch ?
--- 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.
Tested, but it still didn't work in WinXP. :(
Quote from: ollydbg on January 18, 2010, 08:10:44 AM
Quote from: jens on January 18, 2010, 07:24:51 AM
@ all with this problem:
could you please test the following patch ?
--- 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.
Tested, but it still didn't work in WinXP. :(
confirm this.
I open "default.conf", and can not find a key named "splitterWin".
Quote from: Loaden on January 18, 2010, 08:21:04 AM
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.
Find a discussion about setting sash bar: Nabble - wxPython-users - When to SetSashPosition of splitter ? (http://old.nabble.com/When-to-SetSashPosition-of-splitter---td19959677.html)
Just a reminder, I get the wrong behavior in both "float window of Symbols browser" or "docked inside the management pane". Windows XP.
In windows, I have debug these code in the constructor of ClassBrowser class:
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();
it is quite strange:
I try to write the "450", but the next statement, I GetSashPosition, it is "pos=96".....
Quote from: ollydbg on February 26, 2010, 06:27:05 AM
In windows, I have debug these code in the constructor of ClassBrowser class:
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();
it is quite strange:
I try to write the "450", but the next statement, I GetSashPosition, it is "pos=96".....
As I posted before:
Quote from: jens on January 18, 2010, 07:24:51 AM
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.
As we see that does not work on windows.
I can debug this issue on windows, if I find the time.
Maybe it's possible to work around this issue.
Thanks jens. Hope we can find a wrokaround under Windows.
By the way:
I have tried:
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashGravity(1.0);
XRCCTRL(*this, "splitterWin", wxSplitterWindow)->SetSashPosition(0, false);
It is expect that the top window will be resized referring to
http://docs.wxwidgets.org/2.8/wx_wxsplitterwindow.html#wxsplitterwindowsetsashgravity
But the result is still the same, the bottom pane get resized.
Hi all,
the problem lies in this code:
m_pClassBrowser = new ClassBrowser(Manager::Get()->GetProjectManager()->GetNotebook(), this);
Manager::Get()->GetProjectManager()->GetNotebook()->AddPage(m_pClassBrowser, _("Symbols"));
First the classbrowser is created only as a child of the Notebook (wrong size)
and then it get assigned to the notebook as page and classbrowser will be resized to the right size.
So i made a patch, where the sashposition will be set after the assigned to the notebook as a page.
I hope you understand, what i would like to say :lol:
greets GeO
[attachment deleted by admin]
Works well now!
Thanks!
@GeO (http://forums.next.codeblocks.org/index.php?action=profile;u=8928)
Thanks a branch!!!
I have applied in my local copy, and it works quite well!!!
I say: this is a bug fix, and should be applied in the trunk before the next official release. :D
@jens or Morten
Just a reminder, can you apply this patch to solve the sash bar problem before the next stable C::B release?
Thanks.
Quote from: ollydbg on April 27, 2010, 07:23:50 AM
@jens or Morten
Just a reminder, can you apply this patch to solve the sash bar problem before the next stable C::B release?
Thanks.
I just tested it on linux: and it does not work !
Don't know why, no time to digg into it deeper at the moment.
So I am against using it at the moment.
Ok, this patch at least works under Windows. :D
Quote from: ollydbg on April 27, 2010, 08:45:30 AM
Ok, this patch at least works under Windows. :D
For me it works without this patch on windows (xp sp3, wx2.8.10, gcc 4.4)
Until apply this patch, it's works well now. (XPSP3)
Tonight, I will test it in ArchLinux. and will report that.
Jens, could it be that you are using the symbol browser as a floating pane on linux?
If so this patch should solve it too.
HTH GeO
[attachment deleted by admin]
Quote from: jens on April 27, 2010, 08:42:40 AM
Quote from: ollydbg on April 27, 2010, 07:23:50 AM
@jens or Morten
Just a reminder, can you apply this patch to solve the sash bar problem before the next stable C::B release?
Thanks.
I just tested it on linux: and it does not work !
Don't know why, no time to digg into it deeper at the moment.
So I am against using it at the moment.
I tested it on ArchLinux, and it works well!
What's you wxWidgets's version? My wx is 2.8.10.