We have used the UltraMaskedEdit control for several years. Suddenly characters change vertical alignment in our strings. In other words if you type "123" the "1" is sometimes shifted up in the string a few pixels. A little testing revealed that the character is actually at the top of the space occupied by all the characters in the font while the un-shifted characters occupy the middle of the font space. Has anyone else seen and fixed this issue? The control is part of a winforms app that has been in production for quite a while, this behavior is very recent however. Thanks
Related
For university, we need to make a game in Unity that is controlled with an Arduino. My idea was a hacking game where the Arduino acts as the 'hacking device' when hacking something in the game. The arduino would have a screen and on that screen would be a basic command-line interface that lets me input simple commands to 'hack' but I've been having trouble regarding text and clearing it.
I've been able to use unity to send typed characters to the display as-well as a backspace function (pressing backspace would remove last character in the string)
I first had issue with clearing all the text when writing (calling tft.print doesn't clear any previous text). I was using fillScreen which was slow. I found out setTextColor had a second argument that let me just set all certain colored text to a different color. Setting it to black would essentially clear it.
This made it update pretty much instantly when writing to the screen but I now had a new issue, backspace would no longer would.
My understand is that when removing the character, it's color won't be updated when calling setTextColor leaving it on the screen until a restart/fillScreen is called.
I'm not really sure how to solve this and all google searches turn up little to no help.
Here's my code for updating the text:
void updateString(char c){
tft.setTextColor(WHITE,BLACK);
if(c!='<'){
//Add new character to end of string
str.concat(String(c));
}
else if(c=='<' && str.length()>2){
//Remove last character in string
str.remove(str.length()-1);
}
//Set cursor back to 0,0
tft.setCursor(0,0);
//Display text
tft.print(str);
}
I'd appreciate any help.
Maybe, use a similar function to tft.clear() each time you refresh the screen or you can draw a filled square of the background on the text so it looks like it has been erased then you rewrite the text.
Sounds like you are using proportionally-spaced fonts instead of the original classic fonts that ships with Adafruit_GFX. Historically, when using the default classic fonts one could set the background color option of the text to the same color as the background of the screen (usually black). This would overwrite the old screen contents with new data and work because the characters using the classic fonts are a uniform size. When using proportionally-spaced fonts, the background color option for the font is disabled by design.
This was presumably because of memory requirements and speed on slower AVR's. Regardless, when using proportionally-spaced fonts the background color feature won't work due to non-uniform sized characters overlapping the same regions as adjacent characters.
There are two work-arounds to this. Adafruit says in order to replace previously drawn text when using custom fonts you can either:
Use getTextBounds() to determine the smallest rectangle that encloses a
string and then erase that area using fillRect() prior to drawing
the new text. OR
Create an offscreen bitmap using GFXcanvas1 for a fixed size area,
draw the text in the GFXcanvas1 object and then copy to the screen
using drawBitmap().
Note that options 1 & 2 above are mutually exclusive. The second method requires more memory. The first method isn't perfect and produces some small amount of flicker, but is in general acceptable if coded carefully.
I hope that I have understood what the nature of your problem is and answered it in a satisfactory manner. If nothing else, at least now you know why custom font's will not work with the so called background color feature that works with the original 'classic' Adafruit fonts.
Nikki Cooper
I am attempting to put the final touches on a maze program I have been writing. I have used Unicode to delimit the walls and paths however because of the (horizontal) line spacing I can't quite get it to look compact enough. I have attached two screenshots. I'm just escaping the newline "\n" in order to print each row. Can the distance between lines be adjusted or am I stuck with this "gappy" representation?
My output:
What I am trying to closely represent:
Assuming you aren't printing double newlines, this is outside the scope of standard C++, it does not provide facilities for controlling terminal in a standard way.
Solutions:
You could provide a launcher script, which opens a new terminal window with specific font and runs your app in it.
You could use some platform specific method to change background color (ANSI codes work in unixy terminals, or use Win32 API for Windows terminal, ncurses library on Unix-like environments) and print just spaces in different colors.
Use a GUI library/framework to get complete control on what is drawn (I'd use Qt for C++ GUI app).
TBH if you want pixel-accurate rendering use a proper rendering API, such as OpenGL.
From a text rendering point of view you don't say what you are rendering to. Assuming something like a terminal console or shell window then the layout beyond characters and newlines is nothing to do with your program; the visual representation is entirely determined by the shell you are rendering to.
Firstly, check that you are genuinely printing a line per maze scan line, and not interleaving with spurious newlines. Assuming that is ruled out, the problem is that the unicode glyph is not a full block. So you must somehow set the font or choose another glyph which is a full block.
Usually console windows are 80 characters wide by 22 or 24 characters high, and characters are 8 pixels wide by 19 pixels high. So it's very far from a square grid, and you might want to bias the maze to reflect that and provide a better visual appearance (eg make 2 pixel-wide vertical corridors much more common than 2-pievel wide horizontal corridors).
Do check the binary image library fonts, you might find them useful.
https://github.com/MalcolmMcLean/binaryimagelibrary
I'd like to ask what's the simplest way of writing the chess unicode characters in a console window in C++? (♙♘♗♖♕♔♟♞♝♜♛♚) They are part of the "Miscellaneous Symbols" block in unicode. https://en.wikipedia.org/wiki/Chess_symbols_in_Unicode
I also want to print characters with square size, right now my chess board is not square, because each character is a rectangle and not a square.
It'd also be good to be able to write with ordinary non-square characters below the chess board, but that might be impossible? To mix different fonts/formattings in the same console window?
Ok, thanks in advance! :)
The first part of your question, outputting those characters, is platform-dependent. Linux consoles often use UTF-8, if that is the case you can encode the characters as UTF-8 and write them to standard output. On Windows you can use the Console API (the WriteConsole function):
HANDLE handle = GetStandardHandle(STD_OUTPUT_HANDLE);
DWORD written = 0;
// explicitly call the wide version (which always accepts UTF-16)
WriteConsoleW(handle, L"\u2658", 1, &written, NULL);
One caveat which is hard to work around is that you need a console font containing those characters.
For getting square cells, this is dependent on a lot of specifics about the way the console renders text. If it uses font substitution, then there is a chance the text will not actually be monospaced.
Now, if you have a console font with these characters, and if that font is monospaced, then you may be able to draw a square board by adding some spacing between the characters. You can use block elements like ▌ U+258C — LEFT HALF BLOCK to draw the chequerboard: ▌♘▐█▌ ▐.
I am creating a custom single line edit control, with a custom font in win32 api on windows 7, the font is not a fixed width font, and I need to move caret according to the mouse click, The edit control is not empty and if I know the horizontal position of the mouse click within the window, how do I calculate the number of characters after which I need to move caret to ?
I really am out of ideas, if it was a fixed width font, I would have divided the horizontal mouse click position with average character width, that would have been simpler, doing the same with not a fixed width font, is prone to errors.
Given that it's a single-line control, you probably don't plan on working with immensely long input (at least normally). That being the case, one possibility would be to just store the character positions in an array (or vector, etc.) Then you can use (for example) a binary search in that array to find character positions. Of course, you can do the same even for longer strings--though it can increase storage requirements quite a bit.
This is a familiar problem. You are in essence trying to do hit testing on text and for that you need the location on the screen of each character of the text.
My preferred strategy is to calculate an array of RECT, one for each character of displayed text. The array needs to be updated when text is added or deleted, but it easily handles single or multiple lines. The function GetCharWidth32 retrieves all the widths for a string of text in a particular font selected into a DC. For single line one call is enough, and calculating the array of RECTs is simple. It's not much harder to do multiline.
Handle the mouse down message, loop through the array and find the right character. A brute force search is plenty fast enough.
This method is simple and easily generalises to a range of similar problems.
In Visual Studio you need to set the extended window style to get a reading-order of right to left (WS_EX_LAYOUTRTL). Why is this required since if I'm using UNICODE and displaying Arabic characters the only possible way to display it is right-to-left? I'm surprised the system doesn't simply render it the correct way around. To note: this is on a Windows Mobile system where I've copied the Arial Unicode MS font onto it, which perhaps might explain why it can't cope.
Windows' support for RTL is more complex than just the text: WS_EX_LAYOUTRTL is actually about controling the layout of other elements in the window - from MSDN:
The window layout applies to text but also affects the other GDI elements of the window, including bitmaps, icons, the location of the origin, buttons, cascading tree controls, and whether the horizontal coordinate increases as you go left or right. For example, after an application has set RTL layout, the origin is positioned at the right edge of the window or device, and the number representing the horizontal coordinate increases as you move left.
So if you create a dialog that has this, the dialog will be "flipped" automatically (because the coordinates are reversed). If a scrollbar is present, it will be on the left side of the window, not the right. Treeviews will have the expand/collapse box and connecting lines on the right side, not the left - and so on.
In the case of a static, which doesn't contain other windows, the style may not appear to make much difference - but it likely will flip the justification: a static that is right-justified using SS_RIGHT would likely end up actually left-justified when WS_EX_LAYOUTRTL is used.
Also, as the other answer notes, not all text is spans of a single language. It's possible to have a single string that mixes scripts: you can have L-to-R spans within R-to-L, and vice versa, so having Windows "do the right thing" based on the text used would be very fragile.
Also consider the case of a treeview that displays the filenames running on an Arabic system: the treeview should keep a right-to-left layout (aligned against the right side) even if the user just happens to be browsing a directory or file system that happens to have english filenames.
Long story short: WS_EX_LAYOUTRTL is really about overall window layout, not specifically text direction itself. Even without this flag, you should still get Arabic/Hebrew rendered correctly as R-to-L if using the standard APIs/controls.
Presumably because it can't be determined what you're going to display at the window level - you could be displaying nothing, a language read left to right or a language read right to left. Thus you need to set it explicitly rather than having it attempt to deduce based off incomplete information.