add return values to drawString & drawStringMaxWidth #365
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks! I like the overall idea as it opens up new possibilities. I only just scanned the code briefly and haven't tested it yet. We could keep |
Make the drawString*() functions and getStringWidth() directly convert UTF-8 on the fly if needed. This saves an extra malloc for the converted string in most cases which then needs to be free()d and allows to count drawn chars even for UTF-8 strings later. Keep the utf8ascii() function to not break the API for derived classes.
Return the nuber of characters that was drawn. If this is less then the string length, then the text was too long for the display. This allows e.g. for custom word wrapping.
This allows do scroll easily through longer texts, by noting the number of chars drawn in first line and then starting the text with this offset in the next display cycle
this shows how the return value of drawStringMaxWidth() can be used
|
OK. I did not think of classes derived from OLEDDisplay, when I was removing utf8ascii because it's "only" protected. I rebased the branch on current master and edited the first commit in the series to not remove utf8ascii. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea is, to give the calling code a bit more information about what was drawn.
drawString() will return the number of characters that have been drawn before the display ended, so that the calling code can use this to draw the rest of the string into a new line, or to implement some kind of horizontal scrolling.
drawStringMaxWidth() will return the number of characters drawn in the first line, so that the calling code can start drawing with the second line in the next iteration, to implement a kind of vertical scrolling.
To get the counting of UTF-8 characters right, I removed utf8ascii() and instead convert the strings on the fly while processing. This might save some runtime memory (the copy that holds the decoded string is not needed anymore) and slightly reduce code size, but I have not measured this extensively.
When breaking up lines in drawStringMaxWidth(), trailing and leading spaces in each line are now removed, leading to smoother display, e.g. in TEXT_ALIGN_CENTER mode. This is the only change that might be visible when the other new features (return codes) are not used. Other than that, the code should display identically with unchanged usage.
This is intended as a draft / suggestion for discussion, not necessarily as a finished solution (even though it works well with my test cases ;-))