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 » U++ Library support » U++ Widgets - General questions or Mixed problems » Zooming layouts and different behaviour windows/linux
Zooming layouts and different behaviour windows/linux [message #33470] Wed, 10 August 2011 19:18 Go to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
Hi,

As some of my customers complained about small fonts in windows version of my app, I started do dig a bit inside.
The worst stuff was a RichTextCtrl with a drawing inside, which got completely different scale.

Resuming, with NO changes in code, here the windows (from a full-screen running virtualizer, resolution 1440x900 as native one) :
index.php?t=getfile&id=3411&private=0

You can also notice the picture upper right (a Picture control),
this one is made by aid of Painter + Drawing; internal sizes calculations are based on fixed font size, so the windows version get shrinked (font size 15, windows one 11 IIRC).

Adding this couple of lines makes it better :

#ifdef PLATFORM_WIN32
	SetStdFont(StdFont(15));
	Ctrl::SetZoomSize(Size(147, 21), Size(99, 13));
	InitRichTextZoom();
#endif


index.php?t=getfile&id=3412&private=0

But IMHO it's really an ugly hack... but I had to do it because I was in hurry. It's taken from Linux values and code.
Btw, you can notice that tabs are NOT zoomed vertically, so the 2 editfields at top overlap with tab contents when zoomed, so I
believe it's a bug.... or not ?

Finally, the nice-looking linux version here; that one has fonts quite bigger than windows version, and I don't know why :

index.php?t=getfile&id=3413&private=0

So, some questions :

1) Why are font sizes SO different from windows to linux ?
2) It's correct that tabs are not zoomed vertically ?
3) Applying this :
	Ctrl::SetZoomSize(GetStdFont().GetSize(), Size(99, 13));

Sometimes the "growth" of elements don't match text one, so, for example, for some text sizes the buttons become too small to contain its label. Shouldn't they grow exactly (almost) as the text ?

Ciao

Max
Re: Zooming layouts and different behaviour windows/linux [message #33474 is a reply to message #33470] Thu, 11 August 2011 10:30 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
This couple of lines (another hacky stuff....) fix the tabs height problem. Height calculation is from trial-and-error, as I've not found any "intelligent" way to calculate it exactly :

	TabCtrl::Style& tabCtrl_style = TabCtrl::StyleDefault().Write();
	tabCtrl_style.tabheight = Ctrl::VertLayoutZoom(Font::GetStdFontSize().cy);


Thinking a bit more about my size problems, I got following conclusions :

1) Changing default font height *don't* rescale automatically the widgets.... why ? Of course, you can do it with another line of code, but imho it should to automatically.

2) Tabs needs some fixing to behave properly with zooming.
By now their size is based on font size, I guess default one; they don't take in account any scaling.

I think the best solution should be to fix point 1 (make zoom automatical with default font changes) and change automatically Tabs height depending on it.

Ciao

Max
Re: Zooming layouts and different behaviour windows/linux [message #33485 is a reply to message #33474] Fri, 12 August 2011 17:09 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12497
Registered: November 2005
Ultimate Member
mdelfede wrote on Thu, 11 August 2011 04:30

This couple of lines (another hacky stuff....) fix the tabs height problem. Height calculation is from trial-and-error, as I've not found any "intelligent" way to calculate it exactly :

	TabCtrl::Style& tabCtrl_style = TabCtrl::StyleDefault().Write();
	tabCtrl_style.tabheight = Ctrl::VertLayoutZoom(Font::GetStdFontSize().cy);


Thinking a bit more about my size problems, I got following conclusions :

1) Changing default font height *don't* rescale automatically the widgets.... why ? Of course, you can do it with another line of code, but imho it should to automatically.

2) Tabs needs some fixing to behave properly with zooming.
By now their size is based on font size, I guess default one; they don't take in account any scaling.

I think the best solution should be to fix point 1 (make zoom automatical with default font changes) and change automatically Tabs height depending on it.

Ciao

Max



Somewhat weird, as IMO it already depends on font height:

CH_STYLE(TabCtrl, Style, StyleDefault)
{
	font = StdFont();
	tabheight = font.Info().GetHeight() + 8;
	margin = 2;


One possible explanation is that layout is initialized before you change the font. Put sime DDUMPs/DLOGs to find out...

Mirek
Re: Zooming layouts and different behaviour windows/linux [message #33486 is a reply to message #33485] Fri, 12 August 2011 17:23 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
mirek wrote on Fri, 12 August 2011 17:09



Somewhat weird, as IMO it already depends on font height:

CH_STYLE(TabCtrl, Style, StyleDefault)
{
	font = StdFont();
	tabheight = font.Info().GetHeight() + 8;
	margin = 2;


One possible explanation is that layout is initialized before you change the font. Put sime DDUMPs/DLOGs to find out...

Mirek


Yep, it's initialized *before* for sure.
But, here we've got 2 different problems :

1) Calculated font and widgets sizes are quite different from Linux and windows. On windows we get small chars. DPI is set on 96 on my machine, so it's the normal one
I think it would be nicer to have similar font sizes on both, otherwise it's quite hard to have an uniform layout on both environment.

2) There should be a consistent way to resize fonts AND widgets on the fly, or at least at application startup... just after GUI_APP_MAIN.
Now, if I change font size there, layout don't change. If I zoom layout manually, layout changes, but tabs vertical sizes don't.

Max
Re: Zooming layouts and different behaviour windows/linux [message #33487 is a reply to message #33486] Fri, 12 August 2011 17:28 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12497
Registered: November 2005
Ultimate Member
mdelfede wrote on Fri, 12 August 2011 11:23

mirek wrote on Fri, 12 August 2011 17:09



Somewhat weird, as IMO it already depends on font height:

CH_STYLE(TabCtrl, Style, StyleDefault)
{
	font = StdFont();
	tabheight = font.Info().GetHeight() + 8;
	margin = 2;


One possible explanation is that layout is initialized before you change the font. Put sime DDUMPs/DLOGs to find out...

Mirek


Yep, it's initialized *before* for sure.
But, here we've got 2 different problems :

1) Calculated font and widgets sizes are quite different from Linux and windows. On windows we get small chars. DPI is set on 96 on my machine, so it's the normal one
I think it would be nicer to have similar font sizes on both, otherwise it's quite hard to have an uniform layout on both environment.

2) There should be a consistent way to resize fonts AND widgets on the fly, or at least at application startup... just after GUI_APP_MAIN.
Now, if I change font size there, layout don't change. If I zoom layout manually, layout changes, but tabs vertical sizes don't.

Max



IMO, font size should basically follow the font size of host machine - that is what is chameleon for...

Now, it is unfortunately true that chameleon picks values only at beginning. However, if you would want to change it during program run, you would have to have some way how to set new values everywhere value is present. E.g. we have something like AttrText with SetFont method that is supposed to fill ArrayCtrl - you would have to refill ArrayCtrl if settings change. That IMO would require a lot of work for client code....

Re: Zooming layouts and different behaviour windows/linux [message #33488 is a reply to message #33487] Fri, 12 August 2011 17:34 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
mirek wrote on Fri, 12 August 2011 17:28



IMO, font size should basically follow the font size of host machine - that is what is chameleon for...

Now, it is unfortunately true that chameleon picks values only at beginning. However, if you would want to change it during program run, you would have to have some way how to set new values everywhere value is present. E.g. we have something like AttrText with SetFont method that is supposed to fill ArrayCtrl - you would have to refill ArrayCtrl if settings change. That IMO would require a lot of work for client code....




It's true, but it doesn't seem to me that fonts are *so* different.... windows are smaller, of course, but the difference spotted by Upp is huge.

Anyways, it should be a way to adjust fonts/layouts sizes *before* chamaleon grab them... otherwise, resizing fonts is useless.
What about some way to call an user function that do the job before Upp does its settings ? maybe with a #define which, when set, calls an user function, or something like this....

Max
Re: Zooming layouts and different behaviour windows/linux [message #33490 is a reply to message #33488] Sat, 13 August 2011 03:12 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12497
Registered: November 2005
Ultimate Member
mdelfede wrote on Fri, 12 August 2011 11:34

mirek wrote on Fri, 12 August 2011 17:28



IMO, font size should basically follow the font size of host machine - that is what is chameleon for...

Now, it is unfortunately true that chameleon picks values only at beginning. However, if you would want to change it during program run, you would have to have some way how to set new values everywhere value is present. E.g. we have something like AttrText with SetFont method that is supposed to fill ArrayCtrl - you would have to refill ArrayCtrl if settings change. That IMO would require a lot of work for client code....




It's true, but it doesn't seem to me that fonts are *so* different.... windows are smaller, of course, but the difference spotted by Upp is huge.



If the font size differs from one that is present on host machine, well, that is another issue, one worth fixing. I have already pointed out where the font size is fetched from gtk...

Quote:


Anyways, it should be a way to adjust fonts/layouts sizes *before* chamaleon grab them... otherwise, resizing fonts is useless.
What about some way to call an user function that do the job before Upp does its settings ? maybe with a #define which, when set, calls an user function, or something like this....



Putting it to the beginning of GUI_APP_MAIN should definitely work. Please put breakpoint to e.g. TabCtrl chameleon init to find out where it gets called from... (and then tell me).

Mirek
Re: Zooming layouts and different behaviour windows/linux [message #33500 is a reply to message #33490] Sun, 14 August 2011 02:13 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
mirek wrote on Sat, 13 August 2011 03:12


If the font size differs from one that is present on host machine, well, that is another issue, one worth fixing. I have already pointed out where the font size is fetched from gtk...




ops, I've missed that post.

Quote:


Putting it to the beginning of GUI_APP_MAIN should definitely work. Please put breakpoint to e.g. TabCtrl chameleon init to find out where it gets called from... (and then tell me).



It doesn't, at least, on my app if I change font size just after GUI_APP_MAIN i does resize fonts, but not layout.
As you can see in my second posted picture, I've got to resize "manually" the layout with the ugly SetZoomSize(), but tabs don't get resized because Chamaleon calculates its size before.
I had to change manually "tabheigh" to make it better.

I'll do some check on next days and I'll report you.

Ciao

Max
Re: Zooming layouts and different behaviour windows/linux [message #33503 is a reply to message #33500] Sun, 14 August 2011 17:50 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
mhhh... I tried in Linux, putting a breakpoint here :

CH_STYLE(TabCtrl, Style, StyleDefault)
{
	font = StdFont();
	tabheight = font.Info().GetHeight() + 8;
	margin = 2;
	sel = Rect(2, 2, 2, 2);


and one just at the beginning of GUI_APP_MAIN.
The CH_STYLE is hit BEFORE, so tabs get wrong height.
Here the backtrace after debug hit :

Upp::TabCtrl__Style__StyleDefault::Init (this=0x222b2c0) at /home/massimo/sources/upp-svn/uppsrc/CtrlLib/TabCtrl.cpp:7
Upp::TabCtrl::StyleDefault () at /home/massimo/sources/upp-svn/uppsrc/CtrlLib/TabCtrl.cpp:5
Upp::ChHostSkin () at /home/massimo/sources/upp-svn/uppsrc/CtrlLib/ChGtk.cpp:483
Upp::Ctrl::ChSync () at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/Ctrl.cpp:908
Upp::Ctrl::InitX11 (display=0x0) at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/X11App.cpp:412
main (argc=1, argv=0x7fffffffe698, envptr=0x7fffffffe6a8) at /home/massimo/sources/upp-svn/TimberStruct/TimberStruct/TimberStruct.cpp:727


ciao

Max


p.s.: my ide hangs on windows when I run under debugger with breakpoint set. Is my problem or a but ? Using MSC9 and related sdk.

[Updated on: Sun, 14 August 2011 20:45]

Report message to a moderator

Re: Zooming layouts and different behaviour windows/linux [message #33506 is a reply to message #33503] Mon, 15 August 2011 15:28 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12497
Registered: November 2005
Ultimate Member
OK, I have tried to make chameleon detect changes made to the font later, so perhaps it will now work...
Re: Zooming layouts and different behaviour windows/linux [message #33511 is a reply to message #33470] Wed, 17 August 2011 13:43 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
Yep it works now... it's enough to change font height on GUI_APP_MAIN and all layouts gets resized.

Thank you Mirek !

Max
Re: Zooming layouts and different behaviour windows/linux [message #33512 is a reply to message #33506] Wed, 17 August 2011 19:12 Go to previous messageGo to next message
Sender Ghost is currently offline  Sender Ghost
Messages: 299
Registered: November 2008
Experienced Member
Hello, Mirek and Massimo.

mirek wrote on Mon, 15 August 2011 15:28


OK, I have tried to make chameleon detect changes made to the font later, so perhaps it will now work...


It is not necessary, in my opinion, at least for this case. What it really adds is some overhead to check font of each Ctrl in constructor, which noticable for applications with many Ctrls, even for TheIDE.
mdelfede wrote on Wed, 17 August 2011 13:43


Yep it works now... it's enough to change font height on GUI_APP_MAIN and all layouts gets resized.


With changes, which Mirek added, it is possible to change default font size for Ctrls inside GUI_APP_MAIN, as you said. You could achieve the same with INITBLOCK, without such changes before:
#include <CtrlLib/CtrlLib.h>

using namespace Upp;

INITBLOCK {
	SetStdFont(StdFont(20));
}

class App : public TopWindow {
public:
	typedef App CLASSNAME;
	App();

	TabCtrl tabs;
	EditString text;
};

App::App()
{
	Title("TabCtrl size test");
	CenterScreen().Sizeable().MinimizeBox().MaximizeBox();
	SetRect(Size(640, 480));

	Add(tabs.VSizePosZ(4, 4).HSizePosZ(4, 4));
	Add(text.RightPosZ(4, 100).TopPosZ(4, 19));

	tabs.Add("First"); tabs.Add("Second"); tabs.Add("Third");
	text.SetData("Some text");
}

GUI_APP_MAIN
{
	App app;
	app.Run();
}

I suggest you, Massimo, to provide full testcase with your problem, not just screenshots.
I see from screenshots, that different fonts and font sizes used for Windows and Linux environments, which configurable.

[Updated on: Wed, 17 August 2011 19:22]

Report message to a moderator

Re: Zooming layouts and different behaviour windows/linux [message #33513 is a reply to message #33512] Thu, 18 August 2011 01:34 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
Well, I've not seen how much overhead is added, but I guess that a check on a boolean before control creation (which I guess it's all needed to do the job...) is no noticeable overhead.

Your solution, with INITBLOCK, could work too.... but how do you know that INITBLOCK comes *before* chamaleon init ? And, worse,
how do you know your INITBLOCK comes *after* gui init, X11 in particular, without which we could have a crash, I guess ?

I already had bad experiences with INITBLOCKS expecting something already initialized which it wasn't.....

Ciao

Max

edit : about the testcase, IMHO is not needed.
I know we've got different font sizes in windows and linux, and every gui app can show it. What I see is that it seems to me that fonts in Linux are quite big, it seems to me even bigger than default gui fonts, but it's maybe just an illusion....

What I've seen is that my app got too different layout sizes between linux and windows, and I needed a more uniform aspect;
that's more important than keeping default gui font size in this case, so I needed a way to change it at startup.

[Updated on: Thu, 18 August 2011 01:38]

Report message to a moderator

Re: Zooming layouts and different behaviour windows/linux [message #33514 is a reply to message #33513] Thu, 18 August 2011 08:24 Go to previous messageGo to next message
Sender Ghost is currently offline  Sender Ghost
Messages: 299
Registered: November 2008
Experienced Member
mdelfede wrote on Thu, 18 August 2011 01:34


Well, I've not seen how much overhead is added, but I guess that a check on a boolean before control creation (which I guess it's all needed to do the job...) is no noticeable overhead.


Well, may be on Linux it is not very noticable (Ctrl constructor -> SyncCh -> GetStdFont -> InitStdFont).

At first it just felt differently, after starting TheIDE, compiled with new changes. Then I created some (unrealistic) testing application:
#include <CtrlLib/CtrlLib.h>

using namespace Upp;

GUI_APP_MAIN
{
	Array<EditString> list;
	TimeStop e;

	const int n = 1000000;
	for (int i=0; i < n; ++i)
		list.Add();

	PromptOK(AsString(e.Elapsed()));
}

The results for changed source code:
4406
For not changed:
4266

Agree, not much, just 3% difference.

mdelfede wrote on Thu, 18 August 2011 01:34


Your solution, with INITBLOCK, could work too.... but how do you know that INITBLOCK comes *before* chamaleon init ? And, worse,
how do you know your INITBLOCK comes *after* gui init, X11 in particular, without which we could have a crash, I guess ?

I already had bad experiences with INITBLOCKS expecting something already initialized which it wasn't.....


As about INITBLOCK:
"Upp provides a nice solution to do init / deinit work of your package's static or global stuff (i.e. if it's not Plain Ol' Data and needs some function calls).
If your INITBLOCK / EXITBLOCK resides in a .cpp file and the file contains code that is actually referenced (used) somewhere else, everything works as expected, no precautions need to be taken. If not, the linker will drop the file, your init code won't be invoked.
This is because the INITBLOCK / EXITBLOCK actually registers itself in an init facility from upper Upp code. So no code ref downwards is added."

Briefly, it depends from building order, where other INITBLOCKs (residing inside *.icpp files) linked before main code.

mdelfede wrote on Thu, 18 August 2011 01:34


What I've seen is that my app got too different layout sizes between linux and windows, and I needed a more uniform aspect;
that's more important than keeping default gui font size in this case, so I needed a way to change it at startup.


I think, this is because different DPI used for Linux and Windows environments by default. For example, I already increased DPI value on Windows for TFT monitor, but it feels much bigger for CRT monitor. Also the font sizes by default: 8 for Windows, 10 for Linux environment, such as GNOME.

[Updated on: Thu, 18 August 2011 09:22]

Report message to a moderator

Re: Zooming layouts and different behaviour windows/linux [message #33516 is a reply to message #33514] Thu, 18 August 2011 14:59 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1264
Registered: September 2007
Senior Contributor
Sender Ghost wrote on Thu, 18 August 2011 08:24



Agree, not much, just 3% difference.



Inded.... and the advantage is much bigger....

Quote:



"Upp provides a nice solution to do init / deinit work of your package's static or global stuff (i.e. if it's not Plain Ol' Data and needs some function calls)........

.....Briefly, it depends from building order, where other INITBLOCKs (residing inside *.icpp files) linked before main code.



The problem here is *not* if INITBLOCK gets linked; if put in main code, it'll be linked for sure.
The problem is INITBLOCK random order; you can't assume *any* stuff being initialized before it.
So, you can't assume that X11 initialization has been done

Quote:


I think, this is because different DPI used for Linux and Windows
......



Yep, it's for sure... But I can't ask my customers to change Dpi Wink

Ciao

Max
Re: Zooming layouts and different behaviour windows/linux [message #33517 is a reply to message #33516] Thu, 18 August 2011 16:56 Go to previous messageGo to next message
Sender Ghost is currently offline  Sender Ghost
Messages: 299
Registered: November 2008
Experienced Member
mdelfede wrote on Thu, 18 August 2011 14:59


Yep, it's for sure... But I can't ask my customers to change Dpi


There is no problem with DPI, if you like to see small font sizes by default on TFT monitor with different pixel size, than CRT, on Windows. Moreover, this is not related for this case, but it changes layout sizes for U++ application.

The question is: "Do you need this overhead (bigger or smaller), when you didn't change fonts?".

What I really sure, that I will do differently to get normal font sizes in application. It can be problem with RichText, but there is no testcase to fix this for this particular application.
Re: Zooming layouts and different behaviour windows/linux [message #33523 is a reply to message #33506] Fri, 19 August 2011 10:00 Go to previous messageGo to next message
Sender Ghost is currently offline  Sender Ghost
Messages: 299
Registered: November 2008
Experienced Member
mirek wrote on Mon, 15 August 2011 15:28

OK, I have tried to make chameleon detect changes made to the font later, so perhaps it will now work...

Related to latest changes, I think, there is more flexible way. Even there is example on how to do it, e.g. from Ctrl::InitX11 function. What we need is just public Ctrl::ChSync function, instead of private. Then it will be possible to apply font changes not only for concrete Ctrl, but for all of them:
GUI_APP_MAIN
{
	SetStdFont(StdFont(20));
	Ctrl::ChSync();
}


and this without unneeded overhead in Ctrl constructor, when you didn't change fonts.
Re: Zooming layouts and different behaviour windows/linux [message #33589 is a reply to message #33517] Fri, 26 August 2011 14:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12497
Registered: November 2005
Ultimate Member
Sender Ghost wrote on Thu, 18 August 2011 10:56

mdelfede wrote on Thu, 18 August 2011 14:59


Yep, it's for sure... But I can't ask my customers to change Dpi


There is no problem with DPI, if you like to see small font sizes by default on TFT monitor with different pixel size, than CRT, on Windows. Moreover, this is not related for this case, but it changes layout sizes for U++ application.

The question is: "Do you need this overhead (bigger or smaller), when you didn't change fonts?".



I agree, I will optimize.

Mirek
Re: Zooming layouts and different behaviour windows/linux [message #33590 is a reply to message #33589] Sat, 27 August 2011 02:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12497
Registered: November 2005
Ultimate Member
I have tried

#include <CtrlLib/CtrlLib.h>

using namespace Upp;

GUI_APP_MAIN
{
	Array<EditString> list;
	RTIMING("chsync");
	const int n = 1000000;
	for (int i=0; i < n; ++i)
		list.Add();
}


and in release optimal mode, I cannot detect any difference at all...
Re: Zooming layouts and different behaviour windows/linux [message #33591 is a reply to message #33590] Sat, 27 August 2011 10:53 Go to previous messageGo to previous message
Sender Ghost is currently offline  Sender Ghost
Messages: 299
Registered: November 2008
Experienced Member
I have tried your code with RTIMING on Windows XP with different compilers (TDM GCC v4.5.2 and C/C++ compiler from Microsoft Visual Studio 2008 (MSC9)) for Optimal build mode, with following results (for 5 invocations, after and before changes):

TDM GCC v4.5.2:
after changes:
TIMING chsync         :  4.54 s  -  4.54 s  ( 4.54 s  / 1 ), min:  4.54 s , max:  4.54 s , nesting: 1 - 1
TIMING chsync         :  4.53 s  -  4.53 s  ( 4.53 s  / 1 ), min:  4.53 s , max:  4.53 s , nesting: 1 - 1
TIMING chsync         :  4.52 s  -  4.52 s  ( 4.53 s  / 1 ), min:  4.53 s , max:  4.53 s , nesting: 1 - 1
TIMING chsync         :  4.55 s  -  4.55 s  ( 4.55 s  / 1 ), min:  4.55 s , max:  4.55 s , nesting: 1 - 1
TIMING chsync         :  4.55 s  -  4.55 s  ( 4.55 s  / 1 ), min:  4.55 s , max:  4.55 s , nesting: 1 - 1

before changes:
TIMING chsync         :  4.45 s  -  4.45 s  ( 4.45 s  / 1 ), min:  4.45 s , max:  4.45 s , nesting: 1 - 1
TIMING chsync         :  4.45 s  -  4.45 s  ( 4.45 s  / 1 ), min:  4.45 s , max:  4.45 s , nesting: 1 - 1
TIMING chsync         :  4.46 s  -  4.46 s  ( 4.46 s  / 1 ), min:  4.46 s , max:  4.46 s , nesting: 1 - 1
TIMING chsync         :  4.45 s  -  4.45 s  ( 4.45 s  / 1 ), min:  4.45 s , max:  4.45 s , nesting: 1 - 1
TIMING chsync         :  4.44 s  -  4.44 s  ( 4.45 s  / 1 ), min:  4.45 s , max:  4.45 s , nesting: 1 - 1

MSC9:
after changes:
TIMING chsync         :  2.98 s  -  2.98 s  ( 2.98 s  / 1 ), min:  2.98 s , max:  2.98 s , nesting: 1 - 1
TIMING chsync         :  2.99 s  -  2.99 s  ( 2.99 s  / 1 ), min:  2.99 s , max:  2.99 s , nesting: 1 - 1
TIMING chsync         :  2.99 s  -  2.99 s  ( 2.99 s  / 1 ), min:  2.99 s , max:  2.99 s , nesting: 1 - 1
TIMING chsync         :  2.99 s  -  2.99 s  ( 2.99 s  / 1 ), min:  2.99 s , max:  2.99 s , nesting: 1 - 1
TIMING chsync         :  2.99 s  -  2.99 s  ( 2.99 s  / 1 ), min:  2.99 s , max:  2.99 s , nesting: 1 - 1

before changes:
TIMING chsync         :  2.92 s  -  2.92 s  ( 2.92 s  / 1 ), min:  2.92 s , max:  2.92 s , nesting: 1 - 1
TIMING chsync         :  2.94 s  -  2.94 s  ( 2.94 s  / 1 ), min:  2.94 s , max:  2.94 s , nesting: 1 - 1
TIMING chsync         :  2.93 s  -  2.93 s  ( 2.94 s  / 1 ), min:  2.94 s , max:  2.94 s , nesting: 1 - 1
TIMING chsync         :  2.95 s  -  2.95 s  ( 2.95 s  / 1 ), min:  2.95 s , max:  2.95 s , nesting: 1 - 1
TIMING chsync         :  2.93 s  -  2.93 s  ( 2.93 s  / 1 ), min:  2.93 s , max:  2.93 s , nesting: 1 - 1

As I already said, the differences are minor (about 2-3%) in this case. I just suggested to apply font changes "at once", when needed, instead of current approach (in constructor, for each Ctrl). This is "semi automatic" method with its (dis)advantages (compared to current "automatic" method), but implementation could be different.

In conclusion, because current approach exists and differences of changes are minor, there is no need "to fix the fix". On the other hand, it was informative.

[Updated on: Sat, 27 August 2011 11:05]

Report message to a moderator

Previous Topic: PushButton with text in the bottom
Next Topic: What is best way to obtain button info via callback?
Goto Forum:
  


Current Time: Wed May 27 23:56:22 CEST 2020

Total time taken to generate the page: 0.01676 seconds