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 » BUGFIX: ExpanderFrame
BUGFIX: ExpanderFrame [message #27339] Tue, 13 July 2010 08:27 Go to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
ExpanderFrame doesnt recalculate Layout corectly, if surrounding top window changes Size, it only refreshes the scroll bars, when clicking somewhere it does though.. ExpanderFrame::Layout is missing a Repos()

void ExpanderCtrl::Layout()
{
	Repos(); // <<< was missing
	scroll.SetPage(Hv(GetSize()));
	UpdateScrollBar();
}
Re: BUGFIX: ExpanderFrame [message #27343 is a reply to message #27339] Tue, 13 July 2010 11:38 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
Thanks I'll comit the change shortly (my local SVN copy got borken somehow).

ExpanderFrame needs some serious attention though. I tried to skin it recently and discovered that the way styles have been implemented is a bit weird and slightly broken.
Re: BUGFIX: ExpanderFrame [message #27344 is a reply to message #27343] Tue, 13 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
there are several controls that way Smile

thats why i tried to sum things to do on Style in a recent post..
i might sum it up into a documentation or sth.
Re: BUGFIX: ExpanderFrame [message #27359 is a reply to message #27344] Wed, 14 July 2010 13:16 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i tried to prepare as far as i knew, take a look if its like the way you thought of.

i have left StyleStuff only for ExpandFrame, ExpandCtrl doesnt need own, thus one can handle with StyleDefault().

probably SetFont should be added, and font removed from Style. that's like in the other implementations of Ctrl.

cheers

PS: .svn included, for easy compare, current revison 2532 or so..
Re: BUGFIX: ExpanderFrame [message #27360 is a reply to message #27359] Wed, 14 July 2010 13:34 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
Unfortunately the Painting now doesn't work, but I think that is the fault of the bizarre drawing code (originally by me but suplimented by someone else) rather than the style changes. I'll fix that up and then commit it.
Re: BUGFIX: ExpanderFrame [message #27380 is a reply to message #27360] Thu, 15 July 2010 11:50 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
I've re-written the painting routines completely and expanded the style flexibility so that the previous hacks to make ButtonStyle work are no longer necessary.

The only problem is that vertical usage will require the developer to create their own skin but I don't think anyone will actually use it like that anyway.

Changes are in the SVN.

[Updated on: Thu, 15 July 2010 11:50]

Report message to a moderator

Re: BUGFIX: ExpanderFrame [message #27381 is a reply to message #27380] Thu, 15 July 2010 11:56 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
Also, my take on the SetFont / Style-font issue is that SetFont is used on Ctrls when the text is the Data (like an EditField) and/or you will want to set the font through the designer, which you cannot do if it's in the Style.

For Ctrls like Button I think it is correct that the font is in the style because 99% of the time you just want it to match the OS theme.

You could I suppose move font for EditFields and similar into their Styles and then have an optional override through SetFont, but it's a bit cumbersome. It would offer advantages for skjinning though.

[Updated on: Thu, 15 July 2010 11:56]

Report message to a moderator

Re: BUGFIX: ExpanderFrame [message #27385 is a reply to message #27381] Thu, 15 July 2010 13:55 Go to previous message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Quote:


SetFont is used on Ctrls when the text is the Data


good point Smile, but what do when Button should be SetFont()able by Designer? to take the sideways over Style Change is then, kinda unhandly..

generally speaking...is StdFont() i.e. determined by Chameleon? if so, it should be considered style part. if not, well, keep it out.
but it should be part of, since OS style infos contain System / Title font etc...

we could use here same handling as with style. AFAIK Font is handled as copy instance, not as static instance, i.e. in
Font GetStdFont();

while Style is returned as const Style &

Previous Topic: X11 Windowed control and others
Next Topic: Docking: Bug Fix:
Goto Forum:
  


Current Time: Thu Mar 28 22:28:28 CET 2024

Total time taken to generate the page: 0.01468 seconds