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.

The one on "Syntax highlighting" tab is not as well-thought. I recommend to change it to the drop choice similar to the one on "IDE" tab. At the moment we can have these entries
1. light theme (stick with light theme, what the "white theme" buttom will do currently);
2. dark theme (stick with dark theme, what the "Dark theme" button will do currently);
3. "Use host theme"(similar to what the similar one on "IDE" tab would do);
4. "Use default colors" ( what the Restore default colors button would do).

Lance wrote on Sun, 13 October 2024 13:28

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

Another pretty though nut to crack...

What will be the equivalent of choosing the text color in the dark mode?

Not that you are editing text for both modes. We handle, barely, translation of light theme colors to dark theme colors, but is the user, while editing topic++, supposed to select light mode colors (as is now) or dark mode colors that will look different in light mode?

Anyway, all in all, I am postponing this after the release...

Lance wrote on Sun, 13 October 2024 13:28

The one on "Syntax highlighting" tab is not as well-thought. I recommend to change it to the drop choice similar to the one on "IDE" tab. At the moment we can have these entries
1. light theme (stick with light theme, what the "white theme" buttom will do currently);
2. dark theme (stick with dark theme, what the "Dark theme" button will do currently);
3. "Use host theme"(similar to what the similar one on "IDE" tab would do);
4. "Use default colors" ( what the Restore default colors button would do).

This goes into reasonable direction, however I think that the actual choice should be single option:

"User defined colors"

If active, colors are editable (and do not change when mode changes), if not, it is current default colors for dark/light. Maybe current buttons can stay, although only active when colors are editable...

Hi Mirek,

I think this change should be reverted for the time being, as I tried to explain, it creates more problem than it solves (leaves paths percentage encoded).

Best regards,
Oblivion

Code Reformat Issue.

I have been having issues with it for a while. Today I spend a few hours to create a almost mininal example.

#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class S{
	void Set ( Size& sz,
					   int x, int y, int z,
					   int x1, int y1, int z1
					 );

	const S& f(Rect& r, Rect& s)const;
	
	struct D
	{
		int s(int rc)const
		{
			return rc*2;
		}
		
		int e(int rc)const
		{
			return rc*1;
		}
		
		int w(int rc)const
		{
			return rc*3;
		}
		
		int t()const
		{
			return 4;
		}
		
		
		int g(int k)const
		{
			return k;
		}

		void alloc();
		
		void alloc(int a);
		
		int v1;
		int v2;
	};
	D col,row;
};


void S::D::alloc ()
{
}

static void func ( int& x, int& y, int& x1, int& y1, int x2, int y2,
					int x3, int y3, int x4, int y4
				  )
{
}


const S& S::f(Rect& r, Rect& s)const
{
	int t, l, row_section_bottom, n;
	r.top = row.g(r.top);
	s.top = t !=0 && r.top<row.v1 ? row.v1 : r.top;
	
	r.left = col.g(r.left);
	s.left = l != 0 && r.left< col.v1 ? col.v1 : r.left;

	r.bottom = row.g(r.bottom);
	s.bottom = row_section_bottom == 1  && r.bottom > row.v1 + row.v2 ?
		row.v1+row.v2 : r.bottom;

	r.right = col.g(r.right);
	s.right = n == 1  && r.right> col.v1 + col.v2 ?
		col.v1+col.v2 : r.right;
	return *this;
}

Add the code as a separate cpp file in a CtrlLib application, with it current, press Ctrl+I to reformat it. The file before reformat compiles fine, not the reformatted one.

Oops, we just noticed that's the wrong file. We cut the line

int64 data;

from Drawing_en-us.tpp and paste it to the very end of Draw_en-us.tpp. Go back to Draw.h, line 45, right click the dark blue square again, select "copy code reference id".

Switch back to Draw_en-us.tpp, with caret on the newly pasted line, Ctrl-M to bring out the "code reference" dialog. Paste the code reference id we just copied, which should be "Upp::Font::data". Click OK to close the dialog.

So far so good. Click Draw.h tab to bring it current. Oops, an "Invalid memory access!" occurs. If it doesn't, move mouse to over the blue square beside line 45 to show a help content. It happened to me twice, verified.

This error can be fixed in the following way. When restarting theide, you will be prompted to disable Assist features, select "Yes", go to the tpp file, delete thr problematic help line. Then use menu Setup/Settings, on Assist tab, check the first item "Assist libclang parser is enabled..." to reenable Assit++.

Lance wrote on Sat, 12 October 2024 20:20

Code Reformat Issue.

I have been having issues with it for a while. Today I spend a few hours to create a almost mininal example.

#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class S{
	void Set ( Size& sz,
					   int x, int y, int z,
					   int x1, int y1, int z1
					 );

	const S& f(Rect& r, Rect& s)const;
	
	struct D
	{
		int s(int rc)const
		{
			return rc*2;
		}
		
		int e(int rc)const
		{
			return rc*1;
		}
		
		int w(int rc)const
		{
			return rc*3;
		}
		
		int t()const
		{
			return 4;
		}
		
		
		int g(int k)const
		{
			return k;
		}

		void alloc();
		
		void alloc(int a);
		
		int v1;
		int v2;
	};
	D col,row;
};


void S::D::alloc ()
{
}

static void func ( int& x, int& y, int& x1, int& y1, int x2, int y2,
					int x3, int y3, int x4, int y4
				  )
{
}


const S& S::f(Rect& r, Rect& s)const
{
	int t, l, row_section_bottom, n;
	r.top = row.g(r.top);
	s.top = t !=0 && r.top<row.v1 ? row.v1 : r.top;
	
	r.left = col.g(r.left);
	s.left = l != 0 && r.left< col.v1 ? col.v1 : r.left;

	r.bottom = row.g(r.bottom);
	s.bottom = row_section_bottom == 1  && r.bottom > row.v1 + row.v2 ?
		row.v1+row.v2 : r.bottom;

	r.right = col.g(r.right);
	s.right = n == 1  && r.right> col.v1 + col.v2 ?
		col.v1+col.v2 : r.right;
	return *this;
}

Add the code as a separate cpp file in a CtrlLib application, with it current, press Ctrl+I to reformat it. The file before reformat compiles fine, not the reformatted one.

Works for me in windows and works in Ubuntu. Unfortunately, this feature is now using clang-format that can be different per distro...

Would be nice to give me a hint which host platform is in use...

Also, if nothing helps, please post reformatted text as well.

Mirek

#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class S {
	void Set(Size& sz, int x, int y, int z, int x1, int y1, int z1);

	const S& f(Rect& r, Rect& s) const;

	struct D {
		int s(int rc) const { return rc * 2; }

		int e(int rc) const { return rc * 1; }

		int w(int rc) const { return rc * 3; }

		int t() const { return 4; }

		int g(int k) const { return k; }

		void alloc();

		void alloc(int a);

		int v1;
		int v2;
	};
	D col, row;
};

void S::D::alloc() {}

static void func(int& x, int& y, int& x1, int& y1, int x2, int y2, int x3, int y3, int x4,
                 int y4)
{
}

const S& S::f(Rect& r, Rect& s) const
{
	int t, l, row_section_bottom, n;
	r.top = row.g(r.top);
	s.top = t != 0 && r.top < row.v1 ? row.v1 : r.top;
	r.left = col.g(r.left);
	s.left = l != 0 && r.left< col.v1 ? col.v1 : r.left;
	s.left = l != 0 && r.left < col.v1 ? col.v1 : r.left;
	r.bottom = row.g(r.bottom);
	s.bottom = row_section_bottom == 1  && r.bottom > row.v1 + row.v2 ?
	s.bottom =
		row_section_bottom == 1 && r.bottom > row.v1 + row.v2 ? row.v1 + row.v2 : r.bottom;
	r.right = col.g(r.right);
	s.right = n == 1  && r.right> col.v1 + col.v2 ?
	s.right = n == 1 && r.right > col.v1 + col.v2 ? col.v1 + col.v2 : r.right;
}

mirek wrote on Mon, 14 October 2024 10:13

Lance wrote on Sat, 12 October 2024 20:20

Code Reformat Issue.

I have been having issues with it for a while. Today I spend a few hours to create a almost mininal example.

#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class S{
	void Set ( Size& sz,
					   int x, int y, int z,
					   int x1, int y1, int z1
					 );

	const S& f(Rect& r, Rect& s)const;
	
	struct D
	{
		int s(int rc)const
		{
			return rc*2;
		}
		
		int e(int rc)const
		{
			return rc*1;
		}
		
		int w(int rc)const
		{
			return rc*3;
		}
		
		int t()const
		{
			return 4;
		}
		
		
		int g(int k)const
		{
			return k;
		}

		void alloc();
		
		void alloc(int a);
		
		int v1;
		int v2;
	};
	D col,row;
};


void S::D::alloc ()
{
}

static void func ( int& x, int& y, int& x1, int& y1, int x2, int y2,
					int x3, int y3, int x4, int y4
				  )
{
}


const S& S::f(Rect& r, Rect& s)const
{
	int t, l, row_section_bottom, n;
	r.top = row.g(r.top);
	s.top = t !=0 && r.top<row.v1 ? row.v1 : r.top;
	
	r.left = col.g(r.left);
	s.left = l != 0 && r.left< col.v1 ? col.v1 : r.left;

	r.bottom = row.g(r.bottom);
	s.bottom = row_section_bottom == 1  && r.bottom > row.v1 + row.v2 ?
		row.v1+row.v2 : r.bottom;

	r.right = col.g(r.right);
	s.right = n == 1  && r.right> col.v1 + col.v2 ?
		col.v1+col.v2 : r.right;
	return *this;
}

Add the code as a separate cpp file in a CtrlLib application, with it current, press Ctrl+I to reformat it. The file before reformat compiles fine, not the reformatted one.

Works for me in windows and works in Ubuntu. Unfortunately, this feature is now using clang-format that can be different per distro...

Would be nice to give me a hint which host platform is in use...

Also, if nothing helps, please post reformatted text as well.

Mirek

Operation System: Ubuntu 24.04.1 LTS
GNOME version: 46
Windowing System: Wayland
clang-format --version: Ubuntu clang-format version 18.1.3 (1ubuntu1)

Reformatted output

#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class S {
	void Set(Size& sz, int x, int y, int z, int x1, int y1, int z1);

	const S& f(Rect& r, Rect& s) const;

	struct D {
		int s(int rc) const { return rc * 2; }

		int e(int rc) const { return rc * 1; }

		int w(int rc) const { return rc * 3; }

		int t() const { return 4; }

		int g(int k) const { return k; }

		void alloc();

		void alloc(int a);

		int v1;
		int v2;
	};
	D col, row;
};

void S::D::alloc() {}

static void func(int& x, int& y, int& x1, int& y1, int x2, int y2, int x3, int y3, int x4,
                 int y4)
{
}

const S& S::f(Rect& r, Rect& s) const
{
	int t, l, row_section_bottom, n;
	r.top = row.g(r.top);
	s.top = t != 0 && r.top < row.v1 ? row.v1 : r.top;
	r.left = col.g(r.left);
	s.left = l != 0 && r.left< col.v1 ? col.v1 : r.left;
	s.left = l != 0 && r.left < col.v1 ? col.v1 : r.left;
	r.bottom = row.g(r.bottom);
	s.bottom = row_section_bottom == 1  && r.bottom > row.v1 + row.v2 ?
	s.bottom =
		row_section_bottom == 1 && r.bottom > row.v1 + row.v2 ? row.v1 + row.v2 : r.bottom;
	r.right = col.g(r.right);
	s.right = n == 1  && r.right> col.v1 + col.v2 ?
	s.right = n == 1 && r.right > col.v1 + col.v2 ? col.v1 + col.v2 : r.right;
}

Line 46 (?), Line 48 ending (, LIne 50 (?), Line 51 ending ( are highlighted by theide(libclang) to indicate grammer errors.

Cannot reproduce.

Maybe if this could be done without using uppsrc sources and tpp, just in single package, maybe you can prepare for me "crashing package"?

Alternative, can you run it in debugger?

Mirek

It must be some specific clang format setting that I am unable to reproduce. Can you give me some hints? E.g. screenshot of "format with options" window and/or .clang-format file? (It is listed in that dialog).

# .clang-format file for U++ framework

---
BasedOnStyle: LLVM
UseTab: AlignWithSpaces 
IndentWidth: 4
TabWidth: 4
ColumnLimit: 96
---
Language: Cpp
AccessModifierOffset: -4
AllowShortFunctionsOnASingleLine: All
AlwaysBreakTemplateDeclarations: true
BreakBeforeBraces: Stroustrup
BreakConstructorInitializers: BeforeComma
CompactNamespaces: true
DerivePointerAlignment: false
IfMacros: ['ONCELOCK']
PointerAlignment: Left
SpaceBeforeParens: Custom
SpaceBeforeParensOptions:
    AfterControlStatements: false
IndentAccessModifiers: false
IndentPPDirectives: None

mirek wrote on Mon, 14 October 2024 10:17

Cannot reproduce.

Maybe if this could be done without using uppsrc sources and tpp, just in single package, maybe you can prepare for me "crashing package"?

Alternative, can you run it in debugger?

Mirek

I wasn't able to reproduce it in a new, small project. I tried to abuse logs branch to create a n instance but couldn't.

Could you try to unzip the 3 tpp files that's changed and replace their namesakes in uppsrc/Draw/src.tpp folder?

Then somehow go to Draw/Draw.h, line 45, try to display a topic++ help window for "int64 data".

Thanks!

mirek wrote on Mon, 14 October 2024 10:13

Lance wrote on Sat, 12 October 2024 20:20

Code Reformat Issue.

I have been having issues with it for a while. Today I spend a few hours to create a almost mininal example.

#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class S{
	void Set ( Size& sz,
					   int x, int y, int z,
					   int x1, int y1, int z1
					 );

	const S& f(Rect& r, Rect& s)const;
	
	struct D
	{
		int s(int rc)const
		{
			return rc*2;
		}
		
		int e(int rc)const
		{
			return rc*1;
		}
		
		int w(int rc)const
		{
			return rc*3;
		}
		
		int t()const
		{
			return 4;
		}
		
		
		int g(int k)const
		{
			return k;
		}

		void alloc();
		
		void alloc(int a);
		
		int v1;
		int v2;
	};
	D col,row;
};


void S::D::alloc ()
{
}

static void func ( int& x, int& y, int& x1, int& y1, int x2, int y2,
					int x3, int y3, int x4, int y4
				  )
{
}


const S& S::f(Rect& r, Rect& s)const
{
	int t, l, row_section_bottom, n;
	r.top = row.g(r.top);
	s.top = t !=0 && r.top<row.v1 ? row.v1 : r.top;
	
	r.left = col.g(r.left);
	s.left = l != 0 && r.left< col.v1 ? col.v1 : r.left;

	r.bottom = row.g(r.bottom);
	s.bottom = row_section_bottom == 1  && r.bottom > row.v1 + row.v2 ?
		row.v1+row.v2 : r.bottom;

	r.right = col.g(r.right);
	s.right = n == 1  && r.right> col.v1 + col.v2 ?
		col.v1+col.v2 : r.right;
	return *this;
}

Add the code as a separate cpp file in a CtrlLib application, with it current, press Ctrl+I to reformat it. The file before reformat compiles fine, not the reformatted one.

Works for me in windows and works in Ubuntu. Unfortunately, this feature is now using clang-format that can be different per distro...

Would be nice to give me a hint which host platform is in use...

Also, if nothing helps, please post reformatted text as well.

Mirek

Operation System: Ubuntu 24.04.1 LTS
GNOME version: 46
Windowing System: Wayland
clang-format --version: Ubuntu clang-format version 18.1.3 (1ubuntu1)

Reformatted output

#include <CtrlLib/CtrlLib.h>
using namespace Upp;

class S {
	void Set(Size& sz, int x, int y, int z, int x1, int y1, int z1);

	const S& f(Rect& r, Rect& s) const;

	struct D {
		int s(int rc) const { return rc * 2; }

		int e(int rc) const { return rc * 1; }

		int w(int rc) const { return rc * 3; }

		int t() const { return 4; }

		int g(int k) const { return k; }

		void alloc();

		void alloc(int a);

		int v1;
		int v2;
	};
	D col, row;
};

void S::D::alloc() {}

static void func(int& x, int& y, int& x1, int& y1, int x2, int y2, int x3, int y3, int x4,
                 int y4)
{
}

const S& S::f(Rect& r, Rect& s) const
{
	int t, l, row_section_bottom, n;
	r.top = row.g(r.top);
	s.top = t != 0 && r.top < row.v1 ? row.v1 : r.top;
	r.left = col.g(r.left);
	s.left = l != 0 && r.left< col.v1 ? col.v1 : r.left;
	s.left = l != 0 && r.left < col.v1 ? col.v1 : r.left;
	r.bottom = row.g(r.bottom);
	s.bottom = row_section_bottom == 1  && r.bottom > row.v1 + row.v2 ?
	s.bottom =
		row_section_bottom == 1 && r.bottom > row.v1 + row.v2 ? row.v1 + row.v2 : r.bottom;
	r.right = col.g(r.right);
	s.right = n == 1  && r.right> col.v1 + col.v2 ?
	s.right = n == 1 && r.right > col.v1 + col.v2 ? col.v1 + col.v2 : r.right;
}

Line 46 (?), Line 48 ending (, LIne 50 (?), Line 51 ending ( are highlighted by theide(libclang) to indicate grammer errors.

IDK, there is just 1 .tpp file in .zip (Draw_en-us.tpp) and it seems to be unchanged from the master...

OK, after a bit of thinking I have added some more code to logs branch

https://github.com/ultimatepp/ultimatepp/commit/04c14131cc46 99800ca6fa74421858c26cf3eb43

Can you reproduce the problem and send me those files?

Mirek

mirek wrote on Tue, 15 October 2024 07:31

OK, after a bit of thinking I have added some more code to logs branch

https://github.com/ultimatepp/ultimatepp/commit/04c14131cc46 99800ca6fa74421858c26cf3eb43

Can you reproduce the problem and send me those files?

Mirek

Hello Mirek,

Please see attached.

It appears the one written out is different from what's displaying in theide.

Perfect. I believe it is now fixed in the master, please check.

Mirek

mirek wrote on Tue, 15 October 2024 01:40

IDK, there is just 1 .tpp file in .zip (Draw_en-us.tpp) and it seems to be unchanged from the master...

Sorry my bad. Please try this one instead.

Reproduced and hopefully fixed in the master... Please confirm.

P.S.: Thanks for your patience, hugely appreciated...

void CodeEditor::Paint(Draw& w)
{
	DLOG(Format("====at %` ==========", GetSysTime()));
		DDUMP(GetScreenView());
		DDUMP(GetScreenRect());

BTW, now the master branch also need the DEBUGCODE flag to compile (in release mode) because of code like these

void CodeEditor::Paint(Draw& w)
{
	DLOG(Format("====at %` ==========", GetSysTime()));
		DDUMP(GetScreenView());
		DDUMP(GetScreenRect());

int EditField::GetTextCx(const wchar *txt, int n, bool password, Font fnt) const
{
	if(password)
		return n * font['*'];
	const wchar *s = txt;
	int x = 0;
	while(n--)
		x += GetCharWidth(*s++);
	return x;
}