vertical scroll does not work 100% in c++ MFC Dialog multiline field

Hello,

in 1.jpg, you see the vc++ 6.0 editor. There are 5 fields, 4 of which have EXACTLY the same size. All 5 fields have exactly the same properties (except the ID, of course).

In 2.jpg, you see the dialog as used in the running program. I must say that the size of the 5 fields is recalculated automatically, according to the size of the screen. So maybe due to some rounding errors, the size of the 4 lower windows may vary by one pixel.

Now there are 2 problems, with scrolling:
1.) I see a scrolling bar on the last 2 fields, but no scrolling bar on theother fields. Why ? All 5 fields are used in the very same way, in the cpp part of the program.

2.) at the moment of the screen shot of 2.jpg, the cursor is in the FIRST field, at line 8. But it does not scroll down automatically. I guess that the topmost pixel of line 8 is still visible, and so it does not scroll. But of course I want the program to show me 100% what I am typing. - When I press the downarrow key, then I get what you see in 3.jpg. - I know I could solve it vy trial and error (by adding or removing some pixels in the height of the first window. But this would be a mediocre solution, because as soon as the user has a screen with different size, I cannot guarantee a perfect program anymore.

any idea what causes the bug ?

Yours, Sonja


1.jpg
2.jpg
3.jpg
Sonja_MAsked:
Who is Participating?
 
itsmeandnobodyelseConnect With a Mentor Commented:
>>>> Now how does the math go ?
You need to compare a single line edit field with a double-line one. The difference is the height of the second line without any offsets. If you subtract that from the height of the one-liner you get the height (sum) of both offsets at top and bottom (which should be equal).

>>>> don't change the dialog font the sizes will be the relatively same at any screen."
That was badly expressed. I didn't mean that the controls were sized relatively to the dialog size but relatively to screen resolutions and font sizes. If using the font 8, "MS Sans Serif" (as in your rc) you'll get the same relative size on any device with same resolutions (relative to total screen size). The so-called base dialog units were a ratio of pixels per screen unit in 1/1440 of an inch. The latter is called twips.

>>>> When I pressed the down arrow, it scrolled to the end.
That's a default behavior of the handler that was handling the scroll events. In case of proportional fonts 'going down' isn't well defined. So the handler makes it simple and sets the caret to the end of stream. You can overrule that by using an own handler.




0
 
itsmeandnobodyelseConnect With a Mentor Commented:
to (1)

I would assume the last two edit fields contain spaces.  

Generally, you should have the Auto-VScroll on but not the Vertical Scroll (at least of my knowledge it means that the scrollbar is always visible).

to (2)

If I remember rightly, there is no way for edit controls to prevent from partial lines shown if the size of the multiple lines doesn't match exactyl to dialog size. But when I encountered that issue I simply made my control same size as the visible lines require. If not possible in the resource editor (hold the CTRL key down while sizing) you might open the .rc file with the text editor and update vertical size.

Note, the numbers are not pixels but dialog units. So, as long as you don't change the dialog font the sizes will be the relatively same at any screen.
0
 
itsmeandnobodyelseConnect With a Mentor Commented:
>>>> after DOWN arrow key pressed
I don't think that the down arrow was handled the way you assume. Think of the edit text as a stream and not as a 2d-table. You can't go with the down arrow below the current stream size (you couldn't do that in the text editor of Visual Studio either).

If you nevertheless want to invoke a scroll if the user uses the down arrow at end of the visuable screen, you could do that programmatically by handling WM_SYSKEYDOWN or overload OnSysKeyDown of your class derived from CRichEditCtrl or overload YourDialog::PreTranslateMessage to catch the arrow key when one of the rich edit controls has the focus.
0
 
Sonja_MAuthor Commented:
Hello itsmeandnobody,

below you see the code for the very first rectangle, which produces a invisible line 8.

Now how does the math go ? If I understand the source correctly, the height of the window is 79. Do you mean I would need a multiple of 8, because I have font 8 ? Or what do you mean ? -


you write "Note, the numbers are not pixels but dialog units. So, as long as you don't change the dialog font the sizes will be the relatively same at any screen." I do not believe this. Because I make the window bigger, and the characters on my screen remain in the same size. - Anyway, if I can solve it for ONE size, I can make it accordingly for another size.

Sincerely yours, Sonja


PS: you wrote: >>>> after DOWN arrow key pressed
I don't think that the down arrow was handled the way you assume. Think of the edit text as a stream and not as a 2d-table. You can't go with the down arrow below the current stream size (you couldn't do that in the text editor of Visual Studio either). -> I did NOT go bejond the end of the stream size. I saw line 1..7, but the end of the stream was in the middle of line 8. When I pressed the down arrow, it scrolled to the end.
here you see the source of the very first field: 
 
IDD_X_NOTES_DIALOG DIALOG DISCARDABLE  0, 0, 286, 267
STYLE WS_CHILD
FONT 8, "MS Sans Serif"
BEGIN
    CONTROL         "",IDC_A_RICHEDIT,"RICHEDIT",ES_MULTILINE | ES_AUTOVSCROLL | ES_WANTRETURN | WS_BORDER | WS_VSCROLL | WS_TABSTOP,38,2,248,79

Open in new window

0
All Courses

From novice to tech pro — start learning today.