Update a text area with a string and sting has \n newline char

[FJB2069]

I am trying to update a text area called textTestArea with a string and I want to be able to format the string with a newline character.    Ex "I went to the store \n to buy food"

 

I created a texts called genericText that uses a default font that has wildcard range 0x00-0xFF ,  I also tried having range 0x20-0x7e and wildcard character 0x0A (/n)

here is the text and typography:

 

 

Here is the screen with text area:

in baseview.cpp it creates:

 

 textTestArea.setPosition(397, 26, 237, 55);
 textTestArea.setColor(touchgfx::Color::getColorFromRGB(0, 0, 0));
 textTestArea.setLinespacing(0);
 Unicode::snprintf(textTestAreaBuffer, TEXTTESTAREA_SIZE, "%s", touchgfx::TypedText(T_GENERICTEXT).getText());
 textTestArea.setWildcard(textTestAreaBuffer);
 textTestArea.setTypedText(touchgfx::TypedText(T___SINGLEUSE_E1ZC));
 add(textTestArea);

So now in my view.cpp:

	static const uint16_t TEXTBUFFER_SIZE = 64;
			Unicode::UnicodeChar textBuffer[TEXTBUFFER_SIZE];



		Unicode::snprintf(textBuffer, TEXTBUFFER_SIZE, "I went to store \n to but food");

		textTestArea.setTypedText(TypedText(T___SINGLEUSE_81C4)); // Must match your Texts View ID
		textTestArea.setWildcard(textBuffer);
		textTestArea.setWideTextAction(WIDE_TEXT_WORDWRAP);
		textTestArea.resizeToCurrentText();
		textTestArea.invalidate();

I get "test"  Not I went to the store....

 

I have tried 100 iterations.  I have gotten it to print "I went to the store \n to buy food", but can not get it to acknowledge the \n character.

How is this implemented correctly?

 

[FJB2069]

Could it be the font I am using dies not have the newline character defined?  I read something about creating special characters as glyphs?

[FJB2069]

I tried using vendana font, no difference.

 

So I am able to use this code and it prints a:  

Unicode::snprintf(textTestAreaBuffer, TEXTTESTAREA_SIZE, "%s", "a");
		textTestArea.invalidate();

 this is how the generated textTestArea is in viewbase.cpp

 textTestArea.setXY(397, 26);
 textTestArea.setColor(touchgfx::Color::getColorFromRGB(0, 0, 0));
 textTestArea.setLinespacing(0);
 textTestArea.setWideTextAction(WIDE_TEXT_WORDWRAP);
 Unicode::snprintf(textTestAreaBuffer, TEXTTESTAREA_SIZE, "%s", touchgfx::TypedText(T___SINGLEUSE_J85U).getText());
 textTestArea.setWildcard(textTestAreaBuffer);
 textTestArea.resizeToCurrentText();
 textTestArea.setTypedText(touchgfx::TypedText(T___SINGLEUSE_45YP));
 add(textTestArea);
}

 

But if I try to print  a \n a:  I get ??a

 

	Unicode::snprintf(textTestAreaBuffer, TEXTTESTAREA_SIZE, "%s", "a \n a");
		textTestArea.invalidate();

   Not sure what to try?

[jchernus-fikst]

Could you use typed text in TouchGFX instead of programmatically assembling a multiline string? That's how I've been doing it, with no problems. 

[FJB2069]

like this?

 

It still will not acknowledge \n

wait I can make it like this:

 

 

[jchernus-fikst]

Like that!

Another option is to add text wrapping to your text box, but I suppose you don't as much control around how it wraps.

Our text box is in a container,

And then our code chooses which of three errors to display (via custom title, image, and text) like so (sanitized version):

void ErrorView::setupScreen()
{
 ErrorViewBase::setupScreen();

 TEXTS title_text = T_TEXTERROR;
 TEXTS body_text = T_TEXTERROR;
 uint16_t image_bitmap_id = BITMAP_IMAGE_0_ID;

 const Status status = presenter->getStatus();

 switch (status)
 {
 case Status_ERROR_1:
 image_bitmap_id = BITMAP_IMAGE_1_ID;
 title_text = T_TITLE_1;
 body_text = T_BODY_1;
 break;

 case Status_ERROR_2:
 image_bitmap_id = BITMAP_IMAGE_2_ID;
 title_text = T_TITLE_2;
 body_text = T_BODY_2;
 break;

 case Status_ERROR_3:
 image_bitmap_id = BITMAP_IMAGE_3_ID;
 title_text = T_TITLE_3;
 body_text = T_BODY_3;
 break;

 default:
 break;
 }

 image.setBitmap(Bitmap(image_bitmap_id));
 textTitle.setTypedText(TypedText(title_text));
 textInstructions.setTypedText(TypedText(body_text));

 // vertically center the instructions to the right of the image within its container
 textInstructions.resizeHeightToCurrentText();
 textInstructions.centerY();

 image.invalidate();
 textTitle.invalidate();
 textInstructions.invalidate();
}

 

 

 

[Osman SOYKURT]

Hello @FJB2069 ,

I was able to use the \n but using strncpy function :

void Screen1View::setupScreen()
{
 Screen1ViewBase::setupScreen();
 const char *myNewText = "Hello world\nthis is a test";
 Unicode::strncpy(textArea1Buffer, myNewText, TEXTAREA1_SIZE);
 textArea1.resizeToCurrentText();
 textArea1.invalidate();
}

 

Here's my text config :

and my canvas :

Could you try that and let me know if that works?

[Osman SOYKURT]

Hello @FJB2069 ,

Have you been able to resolve your issue?

[WalterHill]

I've been down this road with Touch GFX and those elusive newlines. It's one of those things that should be simple, but the way C-strings and their internal Unicode functions talk to each other is where it gets messy. You're not alone in wasting hours on this.

The problem is that the moment you use Unicode::snprintf with a simple C string containing \n, things get fragile. It seems like the printf formatter doesn't reliably map that control character into the final Unicode buffer in a way the TextArea consistently respects.

The Winning Code (The Simple Fix)

Ditch the snprintf formatter and go straight to the copy utility:

C++

 

// Your original C-string with the newline
const char *myNewText = "I went to the store \n to buy food"; 

// Use strncpy instead—it's cleaner and handles the \n control character reliably.
Unicode::strncpy(textTestAreaBuffer, myNewText, TEXTTESTAREA_SIZE); 

// This part is crucial, especially since the string has two lines now. 
// If your TextArea isn't tall enough, this forces it to resize and show the second line.
textTestArea.resizeToCurrentText(); 
textTestArea.invalidate(); 

I'm betting you were running into an encoding hiccup or the TextArea's height just wasn't big enough to show the second line once it finally respected the \n. Using strncpy and forcing the resizeToCurrentText() call usually solves this 99% of the time.

After spending six hours debugging something that should have been one line of code, I always reach for the easiest, most reliable comfort food. Nothing complicated, just something that works perfectly every time. That's why I always keep the latest menu really handy, it's the only thing that's consistent when my embedded code isn't.

Let me know if that finally gets rid of the dreaded ! Good luck.