BlocklyProp icon indicating copy to clipboard operation
BlocklyProp copied to clipboard

Badge Display: Display Print Number -> Leftover leading/trailing digit(s)

Open francisbauer opened this issue 6 years ago • 4 comments

When trying to display a count-down of a numeric variable (such as: repeat item from 10 to 1 by -1) using the Display Print Number routine and a constant Display Set Cursor position, the trailing 0 from the 10 is left when the 9 to 1 digits are printed. So on the display you see 10, 90, 80, ...

The following blocklyprop code (translated) demonstrates the issue and also what I did as a work-around, (see the if statement).

// ------ Libraries and Definitions ------
#include "simpletools.h"
#include "badgewxtools.h"

// ------ Global Variables and Objects ------
int item;



// ------ Main Program ------
int main() {
  badge_setup();
  // Second Program
  // Allow the Badge WX to be programmed over WiFi
  high(17);

  "Hello";

  if (0) {}


  clear();
  cursor(0, 0);
  text_size(LARGE);
  oledprint("Francis");
  cursor(1, 1);
  oledprint("Bauer");
  text_size(SMALL);
  while (1) {
    for (item = 10; item >= 0; item--) {
      cursor(6, 4);
      if (item < 10) {
        // Display print bug, it leaves leading/trailing digit
        // Print 0 to remove leading digit.
        oledprint("%d", 0);
      }

      oledprint("%d", item);
      pause(250);

    }
    pause(1000);
  }

}

francisbauer avatar Jul 19 '19 08:07 francisbauer

I think the issue here is that the oledprint() lacks a formatter that defines the width of the output. I expect that this would also happen when the previous displayed value contains more digits that the current display value. For example, display "123" followed by "5" should cause the display to render "125".

zfi avatar Jul 19 '19 17:07 zfi

Thank you, @francisbauer

@MatzElectronics @zfi @Steph-Parallax - This is a common problem when it comes to updating displays with changing numbers (and strings) in-place. I think we should consider a general purpose way to handle it that can apply to many situations, like:

  • A new block that takes any string (which could have been output by any other block), formats it (as below) and outputs a new string
    • To fit within a specified width (expanded or truncated accordingly)
    • Left, center, or right justified within that space
      • Possibly specific-character aligned to a specified position (ie: align a string's decimal point (if any) to be at a specific position)
    • Automatically padded on the left and/or right side of visible characters as appropriate with spaces or zeros (0)

There are many formatting options possible, so it should probably be a customizable-option block to be as simple or as sophisticated as the user needs.

The resulting output can just be displayed on the device in the place of a previous output, over and over again, and it will automatically overwrite what was in that entire space before.

NOTE: The features above need not apply only to numeric strings, but also alpha and alphanumeric.

PropGit avatar Jul 19 '19 17:07 PropGit

For example, display "123" followed by "5" should cause the display to render "125".

Right, if the position of the new value is being altered to "right-justify," but most naturally it ends up as rendering "523". A string formatter block could make it turn into " 5" or "5 " or even " 5 " according to the developer's desire, so that the result is properly viewed. (The issue renderer here is converting my double-spaces into a single space, despite my efforts).

PropGit avatar Jul 19 '19 17:07 PropGit

This should be handled by a new simple-library function first, and it can then be brought out to the blocks. It could be: char* pad_string(char* str, int size, char align); where align is RIGHT, CENTER, or LEFT. If would either pad or clip the string appropriately and return a new string.

MatzElectronics avatar Aug 21 '19 19:08 MatzElectronics