Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
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 Go to previous messageGo to next message
kohait00 is currently offline  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 Go to previous messageGo to next message
mrjt is currently offline  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 Smile

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();

Smile

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 #27201 is a reply to message #27198] Thu, 01 July 2010 18:48 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Quote:


is that your icons



Not guilty Smile
i havent done anything to the icons, i used stuff that has been posted here...

SizePos:
imagine just adding an ArrayCtrl to the tab. not always do you want it to be of SizePos, but maybe only the half, which might look better...introducing a parent ctrl for that, well ofcorse, but i have had performance issues here while using to much of ctrl tree depth, so one seeks where to spare out Smile. nevermind, leave it like that, its consistent.

thanks again for support
Re: TabBar: ordering of tabs by their Value (title) [message #27215 is a reply to message #27110] Sat, 03 July 2010 23:00 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
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 Smile

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

Re: TabBar: ordering of tabs by their Value (title) [message #27216 is a reply to message #27215] Sun, 04 July 2010 10:11 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i consider the new one simpler to use, less code was used, and most important: TabBarCtrl derives from TabBar, so one can access it's helpers as well.. i'd prefer the new version.

the porting is not that much of work actually, i did it as well.
Re: TabBar: ordering of tabs by their Value (title) [message #27218 is a reply to message #27216] Sun, 04 July 2010 15:59 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Well... by now I'll stay with previous one, maybe I'll change it when committed.

Max
Re: TabBar: ordering of tabs by their Value (title) [message #27237 is a reply to message #27218] Wed, 07 July 2010 09:19 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hey mrjt,

what about pushing your current TabBar & co upstrem svn Smile
Behaviour [message #27238 is a reply to message #27237] Wed, 07 July 2010 10:49 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi again,

i noticed the TabBar to behave a bit unlike the typical upp control in terms of forwarding change events (here: SetData)

upp controls: calling SetData() (or respective Set methods) updates internal Control data *without* triggering Action() events. so the programmer can decide whether to trigger an Action after SetData() from code or not. while the UI interaction also updates the internal control data *and* triggers the Action() events.

now TabBar triggers UpdateAction() in SetCursor, which is called from both UI interaction and code, it shouldnt trigger UpdateAction(). this leads to unexpected loop behaviour in some cases (when you receive unexpected Action() callbacks while modifying TabCtrl in code via SetData etc). The recenly added UpdatedCursor doesnt help much here.

RFC
Re: TabBar: ordering of tabs by their Value (title) [message #27239 is a reply to message #27237] Wed, 07 July 2010 11:31 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
Could the SetData be changed to call SetCursor0()? If I remember correctly that should solve the problem.

Sorry I haven't committed it. I'm away on a business trip and I expected to have Internet access at the hotel to do the update but unfortunately it's not available. It's just unacceptable! Laughing )

Feel free to commit it yourself, otherwise I will do it as soon as I'm able.
Re: TabBar: ordering of tabs by their Value (title) [message #27241 is a reply to message #27239] Wed, 07 July 2010 11:58 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
dont have any commit rights in svn yet.. Smile

i will try the SetCursor0 thing..

there is no SetCursor0...

[Updated on: Wed, 07 July 2010 12:05]

Report message to a moderator

Re: TabBar: ordering of tabs by their Value (title) [message #27242 is a reply to message #27241] Wed, 07 July 2010 12:25 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
The Problem is that the UI calls quite a few functions from public interface as well, which makes it difficult to separate, what was ui action and what was API action.

SetCursor() i.e. is involved in
*LeftDown()
*Close()
*CloseAll()
*DoUnstacking()
*DoCloseGroup()
InsertKey()
SetData()

while the (*) versions are as well used in UI. there one needed to separate SetCursor UpdateAction() and call it afterwards somehow.

UpdatePos() should be a Part or even Update() istself, you call UpdateActionRefresh(), but there is no Update() override. so UpdatePos should be it, right?

maybe i can figure out what is there and how to do it..
if you could help, that'd be great.

Re: TabBar: ordering of tabs by their Value (title) [message #27374 is a reply to message #27242] Thu, 15 July 2010 10:33 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
I've fixed this and updated the repository finally. I had some problems committing, so it's taken me a while.
Re: TabBar: ordering of tabs by their Value (title) [message #27376 is a reply to message #27374] Thu, 15 July 2010 10:41 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
thanks a lot, i'll take a look.
Re: TabBar: ordering of tabs by their Value (title) [message #27466 is a reply to message #27376] Mon, 19 July 2010 12:13 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
it works good, thank again
Docking: removed special sorter [message #27515 is a reply to message #27466] Wed, 21 July 2010 16:43 Go to previous messageGo to next message
kohait00 is currently offline  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 Smile
  • Attachment: Docking.rar
    (Size: 8.80KB, Downloaded 237 times)

[Updated on: Wed, 21 July 2010 16:49]

Report message to a moderator

Re: Docking: removed special sorter [message #27516 is a reply to message #27515] Wed, 21 July 2010 18:41 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
You're right, I'd forgotten about that. It's a hangover from when the TabBar didn't have keys.

I've committed a more elegant version that does what you want by storing titles directly.
Re: Docking: removed special sorter [message #27528 is a reply to message #27516] Thu, 22 July 2010 08:39 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
it works fine, thanks a lot.

the only problem remaining on my side is, i cant get rid of the hack to make GetContainer() in DockableCtrl public. i dont know how to access the container otherwise. but it's there where i trigger the SortTabs stuff.

Coming from the way
DockableCtrl & dc = Dockable(myCtrl);
DockLeft(dc);

i only have a DockableCtrl & from which to go on, i can store the ref / pointer somewhere, but no chance to access the DockCont behind it to trigger Titles sorting.

is there a more elegant way to do that? if so i could gladly drop my hack and remain upstream...
Re: Docking: removed special sorter [message #27529 is a reply to message #27528] Thu, 22 July 2010 09:03 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
and another question:

is there an easy way to know which DockableCtrl has been clicked in a tabed view??
Re: Docking: removed special sorter [message #27530 is a reply to message #27529] Thu, 22 July 2010 10:08 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
The whole idea is that DockCont is supposed to be an internal, hidden class since it's where all the ugly stuff happens.

However, I have committed an update that makes GetContainer protected. This means you can inherit from DockableCtrl to create you own class that either exposes GetContainer or the sorting methods.

I guess the Sort interface could be added to DockableCtrl but I want to keep that class relatively simple, plus it wouldn't really be very clear what it's actually doing.

Quote:

is there an easy way to know which DockableCtrl has been clicked in a tabed view??

Ctrl::IsShown() should do that I think
Re: Docking: removed special sorter [message #27531 is a reply to message #27530] Thu, 22 July 2010 10:25 Go to previous messageGo to previous message
kohait00 is currently offline  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

Previous Topic: Doking:Does the Dock Manager work correctly?
Next Topic: HelpViewer Class
Goto Forum:
  


Current Time: Fri Mar 29 08:05:48 CET 2024

Total time taken to generate the page: 0.01347 seconds