A little help with text areas in GLCD lib v3

Other Hardware Displays
1

Hi everyone,
I'm using a mega 2560 and a KS108B GLCD from sparkfun.
I've been trying to define text areas and it seems to compile just fine, but my problem arises when I go to print to the screen.
I use the textArea.CursorTo(0,0) which as I understand will put the cursor at the beginning of the text area, but this doesn't work and when I print something out it just puts it in the top left of the entire screen, not the text area.
I'm also trying to invert the pixels in another text area but instead the while screen gets inverted.
I've been looking at the examples but cannot figure out what I'm doing wrong.
Here is my code:

void setup()
{  
  //graphical LCD
  GLCD.Init(NON_INVERTED);
  GLCD.SetTextMode(SCROLL_UP);
  //for temp sensors
  Wire.begin();
  //menu stuff
  char menu1[ ] = "Option 1";
  char menu2[ ] = "Option 2";
  char menu3[ ] = "Option 3";
}
//text areas
  gText t1; //temperature area
  gText t2; //days remaining
  gText t3; //current selection
  gText t4; //rest of menu
void loop()
{
  t1.DefineArea( 0, 0, 7, 1, SystemFont5x7, SCROLL_UP );
  t2.DefineArea( 85, 0, 8, 1, SystemFont5x7, SCROLL_UP );
  t3.DefineArea( 0, 16, 24, 6, SystemFont5x7, SCROLL_UP );
  t4.DefineArea( 0, 24, 24, 6, SystemFont5x7, SCROLL_UP );
  t3.SetFontColor(WHITE); // set font color 
  t3.ClearArea();
    
  //main menu layout below.  Maybe minor differences when within submenus
  t1.CursorTo(0,0);
  t2.CursorTo(14,0);
  t1.print(avgTemp);
  t1.print(" F");
  t2.print("3 Days");
  t3.CursorTo(0,2);
  t3.print(menu1);
  t4.CursorTo(0,3);
  t4.print(menu2);
  t4.CursorTo(0,4);
  t4.print(menu3);
  t4.CursorTo(0,5);
  t4.print(menu4);

The print code at the bottom is how I've currently got everything to print to the correct area of the screen and I'm fine with that, but I really want help getting one text area to be inverted and the rest normal.

Thanks
-Tyler

2

Please provide a full sample sketch that compiles so that I can make sure I see what you are seeing.
(I had to do a bunch of modifications to the code you posted to get it to compile)

A few things that you should look at:

You don't need to redefine the text areas over and over again.
If you don't need them to change, put them up in setup() vs in loop()
or you can use the constructor to define them:

 gText t1 = gText(x, y, columns, rows, font, mode);

which for t1 would be:

gText t1 =  gText(0, 0, 7, 1, SystemFont5x7, SCROLL_UP);

You don't have to specify SCROLL_UP as that is the default.

I think what is probably causing the issues/confusion is that when using the system5x7 font,
there are not 24 characters across the display. There are only 21 (and a little bit) so really only 21.
There is also a maximum of 8 rows of text for that font.

Text areas 3 and 4 are too large for the display and the location specified.
For both t3 and t4 there is not enough room for 24 characters starting at X pixel 0
For t4 there is not enough room for 6 rows of text starting at Y pixel 24
(from y24 to y63 there are 40 pixels which is 5 rows/lines)
and then the rows of t3 and t4 overlap on the display.

The DefineArea() calls are failing and when the parameters are bad, it gives you a text area that
is the entire display.

Not sure what the intent was, but the t2.CursorTo(14,0) call is attempting to position
outside the text area.
The t2 text area was defined to only be 8 characters across but the CursorTo() is
is trying to jump to column 14. (column 7 would be the highest available)
Currently, the code does not sanity check column,row parameters so funny things
can happen if you try to position outside the text area bounds.

If you don't want to have to figure out the columns and rows in a text area you can
either used the predefined areas or specify the bounds of the text area in pixels instead.
The only draw back if you use pixels vs rows/columns is that you cannot specify the
font at the same time you define the text area and will have to specify the font for the text area
using a separate SelectFont() call.

The included HTML documentation has more details on the api calls and their parameters.

If you look at the v3 documentation you will see that there is a return value for DefineArea() that
indicates whether or not the call succeeds. I will caution you that the return status values are about
to change. In v3.1 all the return codes will be much more consistent than in v3
In 3.1 a 0 status means success and a non zero is a specific status code. This is not the case in v3.
I only only bring this up as a caution if you decide to look at the return value since v3.1 will
break any code that looks at the return values.
I'm always very concerned about backward compatibility but this is a case where there really wasn't
an option to preserve it and provide the needed new functionality going forward.

--- bill

3

Thank for the help!
I got it working now. It was having problems with specifying areas that are off the screen and I didn't catch it until now, but I had overlapping areas for a couple text areas that was also causing a problem. Seems everything is working fine now.
Thanks again
-Tyler