A process for solving the problem of drawing the cursor

When developing an SQL text editor, I accidentally got stuck in the cursor display. The solution process is very consistent with the content in the previous issue resolution article. It is a very good example of solving the problem by comparison. So let's share it.

Background:
1. Due to product requirements, the company decided to develop a text clip to meet the functional requirements.
2. We developed it on our own based on an open-source editor.
3. I have little experience with GDI +, but I only need to draw basic images.

Problem:
When displaying the cursor in the editor, you need to draw the cursor on some occasions. I found that there was a problem with the position of the cursor, and there was always a deviation between the correct position and the offset between two pixels. That is to say, the cursor is at the position of the current row, and the cursor is shifted to about two pixels. This is the conclusion obtained by observing the output of the monitor. Of course, this distance is not enough, but it may feel uncomfortable compared with other editors. So I plan to solve this problem.

The following describes the solution steps and procedures. The first step is to try to adjust the position of the display cursor. Since the cursor position is too high, it is okay to lower the position when the cursor is displayed. Unfortunately, after the position is lowered, the cursor image is not high, but the image is low. No matter how it is adjusted, it cannot be completely different. No problems were found by comparing open-source code. Search for examples on the Internet, but the problem persists after several examples are attempted. The cursor painting is just a simple line drawing operation, so it is really unclear what else will happen. So here we are in trouble.

After consideration, we began to examine the differences between the self-drawn cursor and the cursor lit with Win32 API. I found that the highlighted cursor is displayed normally, and the position of the highlighted cursor is the same as that of the self-drawn mark. This indicates that the location is correct, and the problem lies elsewhere. Well, there is a new clue in this dilemma. So I thought of a way to use different coordinates for the highlighted cursor position and the drawn cursor position, and move the coordinates down two pixels when drawing the cursor. This method is feasible, but it is obviously not perfect, at least it is not in the open source code. After the attempt, we found that the position seemed correct, but there was a little difference between the drawn cursor and the highlighted cursor in shape. Because the height of the entire cursor is about 10 pixels, the difference is not small in proportion, and the user will notice clearly. The problem is still not completely solved.

It is basically a headache here. Since I have never touched the drawing of the cursor before, I began to wonder if something went wrong in some unknown places. After multiple times of Google and comparison of open source code, no cause is found. However, it is certain that the code I wrote may have a very low issue. Because it is very simple code. So I relaxed my attention and paid attention to the entire draw process, that is, all the code in the ondraw method. Through repeated and careful comparisons, we found a suspicious place. That is, when I draw text, the parameters of the painting method specify the high quality and anti-sawtooth effect, but this is not done in the open source code. The fact is clear: if a line is drawn using a high-quality parameter of anti-sawtooth, the line will be a bit virtualized for smooth and sawtooth. So will this be the cause of the problem?

If I answer this question before trying to modify it, I will not. This is because the anti-sawtooth effect only appears when the online bar is not vertical or horizontal. I have this experience when using VC. The cursor I draw now is a vertical line with a height of 10 pixels. However, the current situation is different, because such a simple small problem of creating a straight line cannot be found during repeated checks, so the clue is worth checking. Another reason is that the open source code does not use anti-sawtooth, which is a difference found through comparison, making this clue suspicious. Practice has proved that this is indeed the cause. Modify the code and do not use the anti-sawtooth effect when drawing the cursor, so the problem is solved.