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 » LineEdit, EditFields, DocEdit » Please help debug this program (Re: EditDouble with customized Convert)
Please help debug this program (Re: EditDouble with customized Convert) [message #41312] Sat, 30 November 2013 04:35 Go to next message
Lance is currently offline  Lance
Messages: 381
Registered: March 2007
Senior Member
See attached for a minimal test case.

In the program, numbers are formatted to certain format which works as expected, but when the formatted text is dragging around between the Edits, an assertion failure is caused supposedly because of some inconsistency between the length of the text dragged and that of the text in the internal storage of EditField.

It's highly suspected to be some sort of libary bug. But I stand corrected if it's because I missed some step or what not.



Thank you for your help in advance.
  • Attachment: EditTest.zip
    (Size: 1.12KB, Downloaded 203 times)
Re: Please help debug this program (Re: EditDouble with customized Convert) [message #41313 is a reply to message #41312] Sat, 30 November 2013 04:41 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 381
Registered: March 2007
Senior Member
BTW, I failed to find a way to conveniently format eg

123456.5
to
123,456.50

using existing Upp facilities. It's greatly appreciated if somebody can show me the right way. For example, I use GridCtrl's SummaryRow (or something like that); it accepts a format string and format the column total to that format. It's easy to write a format function, but hard to incorporate it to the Upp::Format(format, ValueArray) facility. If you know how to, please let me know.
Re: Please help debug this program (Re: EditDouble with customized Convert) [message #41321 is a reply to message #41313] Sat, 30 November 2013 16:23 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 381
Registered: March 2007
Senior Member
OK. I figured out.

The problem occurs because I SHOULD HAVE provided a matching filter to NOT TO replace comma with dot (the default behavior it inherits from its parent ConvertDouble), but should instead filter out it. Morale is, Scan/Format/Filter should work together to assure the EditField is in a consistent state.

The second question, if you want to format a double to certain dicimal digits and with thousand separtor, you should:
1. SetLangue properly;
2. The format string should be something like this "%3!nl", which will format the number to 3 decimal points and with localized thousand separtors. Eg, in enUS, 12345.6 will be formatted to 12,345.600.

I had to go through the code to figure it. Maybe a example line can be added to the Format example to save somebody else some trouble in the future.

===============================
CORRECTION: the problem remains after a customized filter has been provided to take care of the comma separator. Now I am almost positive that it's a bug in the library.

I have attached a slightly revised test case. Just drag the text between the edits a few times, you WILL observe erratic behavior.
  • Attachment: EditTest.zip
    (Size: 1.21KB, Downloaded 203 times)

[Updated on: Sat, 30 November 2013 17:05]

Report message to a moderator

Re: Please help debug this program (Re: EditDouble with customized Convert) [message #41370 is a reply to message #41321] Fri, 06 December 2013 18:33 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 381
Registered: March 2007
Senior Member
The following change to EditField::Insert(int, cost WString&) will fix the problem. I believe this should be regarded as a library bug and should be fixed to honor EditField's promise to work with customized Convert.

int EditField::Insert(int pos, const WString& itext)
{

	// omitted many unchanged lines
	//
	// the following test might need to be rewritten 
	// taking the Format/Scan effect into account
	//
	if(ins.GetCount() + text.GetCount() > maxlen) {
		BeepExclamation();
		return 0;
	}
	
	//changes ======================
	int len=text.GetLength();
	text.Insert(pos, ins);
	SetData(GetData()); // might be smarter way to achieve it
	len-=text.GetLength();
	Update();
	return -len;
}


After insert action, the text the EditField held in its internal storage becomes different from what it displays (because of the customized Format). This should not happen. Above code did the synchronization. I feel that it's not the best place to do such synchronization. Mirek will certainly be able to find the best and most economic way to achieve such synchronization, but one is indeed needed.
Re: Please help debug this program (Re: EditDouble with customized Convert) [message #41381 is a reply to message #41370] Mon, 09 December 2013 08:19 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13467
Registered: November 2005
Ultimate Member
Hopefully fixed. Thanks for the report.

Mirek
Re: Please help debug this program (Re: EditDouble with customized Convert) [message #41383 is a reply to message #41381] Mon, 09 December 2013 16:52 Go to previous message
Lance is currently offline  Lance
Messages: 381
Registered: March 2007
Senior Member
Thank you, Mirek!
Previous Topic: Wrap EditString Rect to text
Next Topic: New method with EditorSyntax
Goto Forum:
  


Current Time: Mon Dec 06 16:29:25 CET 2021

Total time taken to generate the page: 0.01063 seconds