|
|
Home » Developing U++ » UppHub » TabBar: ordering of tabs by their Value (title)
Re: TabBar: ordering of tabs by their Value (title) [message #27188 is a reply to message #27184] |
Tue, 29 June 2010 23:32 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
i am still asking myself why the new TabBarCtrl is keeping only the current shown control as child in its pane...
thus no tree inspection is possible. why not having them all in there using Show/Hide, like in one of the early versions or was it in QuickTab, dont remember.
and having the ctrls themselves decide how they should be added (no SizePos by default)?
some hints
TabBarCtrl& TabBarCtrl::InsertCtrl(int ix, Ctrl &ctrl, Value key, Value value, Image icon, String group, bool make_active)
{
ctrls.Add(key, &ctrl);
ctrl.Hide();
pane.Add(ctrl);
TabBar::InsertKey(ix, key, value, icon, group, make_active);
return *this;
}
void TabBarCtrl::SetCtrl(int ix)
{
ASSERT(ix < GetCount());
Value key = TabBar::GetKey(ix);
int _ix = ctrls.Find(key);
if (_ix >= 0)
for(int i = 0; i < ctrls.GetCount(); i++)
{
Ctrl * pc = ctrls[i];
pc->Show(i == _ix);
}
}
a bugfix in RemoveCtrl(Value key)
// Close(key);
CloseKey(key); //should be this one, right
|
|
|
Re: TabBar: ordering of tabs by their Value (title) [message #27198 is a reply to message #27188] |
Thu, 01 July 2010 14:43 |
mrjt
Messages: 705 Registered: March 2007 Location: London
|
Contributor |
|
|
Thanks again, I wrote TabBarCtrl pretty quickly so I knew it would need some improvement.
kohait00 wrote on Tue, 29 June 2010 22:32 | i am still asking myself why the new TabBarCtrl is keeping only the current shown control as child in its pane...
|
Changed so that all ctrls live in the pane. You're right, it's much more sensible
Quote: | and having the ctrls themselves decide how they should be added (no SizePos by default)?
|
I dsagree with this for 2 reasons:
- Always apply SizePos is how it works in TabCtrl
- Not doing it means that you have to remember to do it yourself, which is more prone to errors
If you want to use a layout you just need to use an additional ParentCtrl. Realistically it's not very common that you'd want to add ctrl without SizePos and not be using a Layout template anyway. I'll keep it like it is.
Mindtraveller:
I have added your icons. The cross icons are now part of TabBar::Style, with some helpful shortcut functions to swap them:
struct Style : public TabCtrl::Style
{
Image crosses[3];
Value group_separators[2];
Style & Write() const { return *static_cast<Style *>(&TabCtrl::Style::Write()); }
Style& DefaultCrosses();
Style& Variant1Crosses();
Style& DefaultGroupSeparators();
Style& GroupSeparators(Value horz, Value vert);
Style& NoGroupSeparators() { return GroupSeparators(Value(), Value()); }
};
It's a bit unorthodox but given TabBar's requirment for different styles for LEFT, RIGHT etc. I couldn't think of a better way. The only problem is that your icons are off-center, so they won't work properly with TabBars aligned to the side or bottom, but I haven't decided how to fix that yet.
This means you can this to change the global style for a TabBar to use your crosses with no separator line between groups:
TabBar::StyleDefault().Write().Variant1Crosses().NoGroupSeparators();
I've attached my latest version. TabBarCtrlTest has been modified to include style testing. I still haven't had time to properly test Docking but I'll get everything committed either tomorrow or early next week.
|
|
|
|
Re: TabBar: ordering of tabs by their Value (title) [message #27215 is a reply to message #27110] |
Sat, 03 July 2010 23:00 |
mdelfede
Messages: 1308 Registered: September 2007
|
Ultimate Contributor |
|
|
mrjt wrote on Fri, 25 June 2010 17:57 | Right.
I've modified TabBar so that it can now be used like a Ctrl (outside of a frame) and restricts it's drawing to the correct size. Suprisingly few changes were necessary and a nice side effect has been a slight rendering improvement when the scrollbar is hidden
This means that you can now inherit from it directly to make a TabBarCtrl without the use of any Callbacks and the whole interface exposed.
I have attached a package that contains my implementation of TabBarCtrl a much more comprehensive TabCtrlBarTest. I'm not going to commit it just yet as it needs more testing and I haven't tried it with Docking.
EDIT: See further down-thread for latest version
|
Uhmmmm.... changes to TabBarCtrl interface from my previous one made my app not compatible with it anymore.... so I've got 2 choices... rethink my app interface to TabBarCtrl or regrab my previous one.
Still not sure if the effort of changing my app are worth. Which are the advantages of new TabBarCtrl from previous one ?
Max
Edit :
In detail, you removed following stuffs :
TabBarCtrl::Get()
TabBarCtrl::GetItem()
TabBarCtrl::Add(Ctrl&, String&)
And maybe some others.
Thinking a bit about it, I guess I'll take back my previous version.....
Max
[Updated on: Sat, 03 July 2010 23:04] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
Docking: removed special sorter [message #27515 is a reply to message #27466] |
Wed, 21 July 2010 16:43 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
hi mrjt,
your last commit reomved the special sorter in DockCont, it was nessessary to have, because the DockCont uses the Values as containers for the DockCtrl, not for the titles itself. thats why the weired converter
//DockCont.h
...
//and the sorting itself uses a ValueSorter inside
struct DockValueSort
: public TabBar::TabSort
{
virtual bool operator()(const TabBar::Tab &a, const TabBar::Tab &b) const
{
DockableCtrl* dca = DockCast(a.value);
DockableCtrl* dcb = DockCast(b.value);
if(dca && dcb)
return (*vo)(dca->GetTitle(), dcb->GetTitle());
else
return false;
}
const ValueOrder *vo;
};
DockValueSort tabsorter_inst;
...
void SortTabs(bool b);
void SortTabs(TabBar::TabSort &sort); //should be protected
void SortTabs(ValueOrder &sort);
void SortTabsOnce(ValueOrder &sort);
//DockCOnt.cpp
void DockCont::SortTabs(bool b)
{
tabbar.SortTabs(b);
}
void DockCont::SortTabs(TabBar::TabSort &sort)
{
tabbar.SortTabs(sort);
}
void DockCont::SortTabs(ValueOrder &sort)
{
tabsorter_inst.vo = &sort;
tabbar.SortTabs(tabsorter_inst);
}
void DockCont::SortTabsOnce(ValueOrder &sort)
{
DockValueSort q;
q.vo = &sort;
tabbar.SortTabsOnce(tabsorter_inst);
}
//ctor
tabsorter_inst.vo = &Single<StdValueOrder>();
//ive fixed it, see attachment, if ok please commit soon. my app relys on that
-
Attachment: Docking.rar
(Size: 8.80KB, Downloaded 278 times)
[Updated on: Wed, 21 July 2010 16:49] Report message to a moderator
|
|
|
|
|
|
|
Re: Docking: removed special sorter [message #27531 is a reply to message #27530] |
Thu, 22 July 2010 10:25 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
i'll try both.
isn't IsShown kind of self initiated looking through a list? i thought more of beeing notified when user clicks a docked tab, to know which tab (and thus DockableCtrl it was) because i need to trigger showing some related info on a sidebar.
it's because DockCont::TabSelected does not invoke WhenState for the DockableCtrl to notify that it has been 'set visible'. but it may be that i misunderstand WhenState, beeing STATE 'docked, tabbed' etc. that's my current hack though, so maybe there is a better option
[Updated on: Thu, 22 July 2010 10:32] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Fri Sep 20 09:28:38 CEST 2024
Total time taken to generate the page: 0.03932 seconds
|
|
|