what does "Win32" mean in the description ? does it mean that this version of UPP can be installed in windows-10 32x ?

Hi Mirek,

It seems that Progress::SetPos() 'eats' memory.

#include <CtrlLib/CtrlLib.h>

using namespace Upp;

GUI_APP_MAIN
{
	for(int x=0;x<5;x++){
		Progress progress;
		progress.Create();
		progress.SetTotal(20000);
		for(int i=0;i<20000;i++){
			if(progress.Canceled()) break;
			progress.SetPos(i);
			progress.SetText(Format("MemoryUsedKb %d", MemoryUsedKb()));
		}
		Sleep(2000);
	}
}

Best regards,

Tom

Teste with CLANG, CLANGx64 and MSBT 64, problem not reproduced. Perhaps needs more instructions to reproduce?

mirek wrote on Sun, 29 September 2024 21:55

Teste with CLANG, CLANGx64 and MSBT 64, problem not reproduced. Perhaps needs more instructions to reproduce?

Hi Mirek,

Do you mean that your MemoryUsedKb value did not keep climbing through all the five runs???

First, this is not a normal memory leak catched with debugger. This happens on Windows 11 Professional with all compilers: CLANG, CLANGx64, MSBT22, MSBT22x64. The MemoryUsedKb starts out at around 1200 kB on first start, and then keeps gradually rising up to about 20000.. 30000 kB when the fifth run is complete... and more if we let it run longer with higher values of x.

Best regards,

Tom

GUI_APP_MAIN
{
	SetupValueCache(2000, 1);
	
	for(int x=0;x<5;x++){

Tom1 wrote on Sun, 29 September 2024 22:02

mirek wrote on Sun, 29 September 2024 21:55

Teste with CLANG, CLANGx64 and MSBT 64, problem not reproduced. Perhaps needs more instructions to reproduce?

Hi Mirek,

Do you mean that your MemoryUsedKb value did not keep climbing through all the five runs???

First, this is not a normal memory leak catched with debugger. This happens on Windows 11 Professional with all compilers: CLANG, CLANGx64, MSBT22, MSBT22x64. The MemoryUsedKb starts out at around 1200 kB on first start, and then keeps gradually rising up to about 20000.. 30000 kB when the fifth run is complete... and more if we let it run longer with higher values of x.

Best regards,

Tom

Reproduced: It is a problem of dark mode emulation. I was trying with normal mode first...

It is quite obvious - various variants of progress bar are drawn in normal mode, then converted to DarkTheme and the result is cached.

You can adjust maximum size of cache with

GUI_APP_MAIN
{
	SetupValueCache(2000, 1);
	
	for(int x=0;x<5;x++){

and it stops increasing the memory.

So I do not think this is a problem nor a bug - it is just using general caching mechanism where it is good to cache results for performance reasons.

Mirek

Upon further reflectio I decided that caching progress causes is just trashing the cache, so optimised that out (with the advantage that the result is now actually faster in Win32).

The only downside is that now I have to think whether to apply the similar treatment to scrollbar thumbs... But probably not.

Mirek

two more minor issues (or maybe non-issues).

1. In dark theme, the Topic++ editor is still in light mode. Would be nice if it can melt with environment.

Lance wrote on Sun, 13 October 2024 06:10

two more minor issues (or maybe non-issues).

1. In dark theme, the Topic++ editor is still in light mode. Would be nice if it can melt with environment.

Colors are user setting. I do not know whether user wants it or not. Normally, theide chooses the scheme on the first run, but then user is allowed to change it any way he likes, so it would not be very nice to change the scheme at that point.

Well, maybe we could solve that with having 2 user configurations, one for light one for dark? But in the next release..

1. In dark theme, the Topic++ editor is still in light mode. Would be nice if it can melt with environment.