Currently, my program prints to System.out:
Processing line 1 of 3...
Processing line 2 of 3...
Processing line 3 of 3...
Is there any way to have it replace the line numbers, instead of printing a new line?
Well there are some hacks you can try, but none of them are guaranteed to work everywhere. Escape characters such as \b (backspace) can erase the last character and \r (replace) can erase the last output.
It may or may not work (depending on IDE), but you could try:
System.out.print("Hello");
Thread.sleep(1000);
System.out.print("\rWorld");
However, generally a Swing box should be used (dynamically updating GUI) to measure progress. See Progress Bars.
Related
The Emacs tab seems like three or four tabs(four spaces for each)， I don't know the usage of it.
and the behavior of the "cut line backward" cuts the current space to the start with the above line?What's the logic?It shouldn't match the meaning "cut up to line end" and named "cut up to line beginning"， they're together.So what is that functionality? I fully replace these two editings by selecting to start and end， but if you need deleting the selection，you as well type a space or else. So，the ummatching makes me unhappy.
Appreciate for resorting me!
As you can see, after every text comes a tab, everything is working fine, but after third tab (see output) it generates a space not a tab.
fileWriter = new FileWriter(indexFile, true);
fileWriter.append(id).append("\t");
fileWriter.append(String.valueOf(idx)).append("\t");
fileWriter.append(String.valueOf(pageCount)).append("\t");
fileWriter.append(postal.toUpperCase()).append("\t"); <-- this one
fileWriter.append(address.toUpperCase());
fileWriter.append("\r\n");
My output:
00000347 1 1 FB-6666 DUMMY STREET 1 LAT
The problem comes after "FB-6666".
Any ideas on this?
No, it really is generating a tab - it's just that whatever you're using to view the file is deciding to handle tabs by aligning them to some boundary or other. If you make your postal value FB-6666x I suspect you'll then see a much larger space.
This isn't a problem with the file content at all.
If you want to enforce a certain number of spaces between columns, you'll need to write that many spaces. Alternatively, something else to view the file...
Tabstops don't work this way. As the wikipedia article states,
Tab stops are set manually, and pressing the tab key causes the carriage to go to the next tab stop. In text editors on a computer, the same concept is implemented simplistically with automatic, fixed tab stops.
This means the tabstop will stop at a predefined position in the textfile, not after let's say the space it would take to insert a specific amount of spaces.
It is writing a tab I promise - to convince yourself of this you should either open the resulting file in a hex editor and look at the value in that position, or add another character to the value before the tab and see how the format of the output changes.
I have textview with droid sans mono font. Max line lenght is 10 characters. gettin it by this function.
this.getPaint().breakText(FULLTEXT, 0, 100, true, this.getWidth(), null);
I want lines always full if there is text and not the break halfway or something similar.
If I am using only normal characters like numbers and letters its working but for characters like "." or "," in certain situations the line break.
For example: if i have line:
"0123456789" or ".012345678"
tv is working as i want.. line is full..but with input:
"Y.012345678"
the line break this way:
".xxxxxxxxx"
"012345678Y"
where x are empty spaces.
i want to have multiline, i just dont want empty spaces (just in last line)
If i insert two special character like:
"01234\\.789"
its start breaking halfway if line is full. how i understand it, textview is breaking sentences which are too long for line.
Curently i am inputing different chareacter without this behaviour, but i would be happy if i didn't need too do this. (too much corections need too be done and its messy)
I noticed that descripted behaviour is not on every android version. I have devices with android 2.3.6, 4.0.4 and kindle fire version. I don't have problem on 2.3.6.
Is there a way how to disable this textview behaviour? thanks.
android:singleLine="true"
is the property of textview and edittext which will keep the text on single line. if length of string is too big then text will be truncated but will never go on next line.
I am running a java program from the command line that prints a relatively long string retrieved from a file. Though the string is printed accurately (I am using System.out.println(string)), the line breaks are consistent with the size of my terminal window, which results in words being cut off in the middle and then continued on the next line. Is there a way to change the system print settings so that the string will still fit inside the window but breaks will only occur where there is white space or a hyphenation? Or is the only way to do this to build a simple GUI and use HTML? Thanks!
I have this problem:
The text "ABCD\r\nEFGHJ" loaded from a file is matched with java regex "EFGH". Matcher object of course says start of the matched string is in position 6. The matcher counts \r \n as two positions.
I put the original text in a AWT TextArea Component and then call select(6,10) to highlight the area which was matched. Guess what... it starts highlighting from 'F' letter. One position forward than it should...
If more than 1 pair of crlf precedes matched area then highlighting moves even more forward than it should.
Anyone has any simple solution?
Simple solution: remove all \r from the text... :-P
Not as stupid as it sounds, unless you have inconsistent end of lines (it can happen) and want to keep them unchanged... And that's probably what the component does anyway.
I cant mess with the text because it is protocol data and \r and \n characters have semantics that dont have to do with display or line separation. I just want a component that will treat each one input character separately and treat it as one displayed and counted, no matter how it is displayed.
If the \r\n are consistent, you can remove the \r's before running the regex, then replace them before handing off to whatever is next. Or change a copy, if that works better. This way, your regex finds the position in a way consistent with what AWT is expecting.