Scrolling text gets negated in static control (C++ WinAPI) - c++

Question

I have some weird control,
CreateWindowEx(!tset&USE?WS_EX_OVERLAPPEDWINDOW:0,
tset&USE?"static":"edit",0,WS_CHILD|WS_VISIBLE|
(!tset&USE?ES_MULTILINE|ES_WANTRETURN|ES_AUTOVSCROLL|WS_VSCROLL //when it's edit
:SS_NOTIFY|SS_EDITCONTROL),5,60,390,474,hwnd,HMENU(10),0,0); //when it's static
SetWindowSubclass(GetDlgItem(hwnd,10),tset&USE?BOR:NoMenu,0,0);
whose everything depends on whether themes are active. Here tset is an instance of enum type for bit flags. Everything is fine except scrolling when the control is in static mode. It wasn't receiving WM_MOUSEWHEEL messages, I made it receive them in the following way:
LRESULT CALLBACK BOR(HWND hwnd,UINT msg,WPARAM wp,LPARAM lp,UINT_PTR,DWORD_PTR)
{
if(msg==WM_MOUSEMOVE&&GetDlgCtrlID(hwnd)==10)
{
POINT x{LOWORD(lp),HIWORD(lp)}; ClientToScreen(hwnd,&x);
RECT rc; GetWindowRect(hwnd,&rc); if(PtInRect(&rc,x)&&GetCapture()!=hwnd){SetCapture(hwnd); hwnd3=SetFocus(hwnd);}
if(!PtInRect(&rc,x)&&GetCapture()==hwnd){ReleaseCapture(); SetFocus(hwnd3);} //hwnd3 is an instance of HWND defined in global scope, for giving focus back
}
if(msg==WM_MOUSEWHEEL)
{
RECT rc; GetWindowRect(GetParent(hwnd),&rc);
HRGN x; GetWindowRgn(GetParent(hwnd),x);
ScrollWindowEx(hwnd,0,short(HIWORD(wp)),0,0,x,&rc,SW_INVALIDATE|SW_ERASE);
ShowWindow(GetParent(hwnd),SW_HIDE); ShowWindow(GetParent(hwnd),SW_SHOW);
SetFocus(hwnd);
return 1;
}
return DefSubclassProc(hwnd,msg,wp,lp);
}
Now when mouse enters client area of my control, if it's in static mode, it captures mouse and gets focus. So it intercepts WM_MOUSEWHEEL messages in its subclass callback function and I can scroll my control in the static mode. Here's the exact problem: few milliseconds later, right after its text is scrolled, the window somehow updates itself to its initial unscrolled state. And my efforts get negated. Is it clear why it behaves like this, and how to fix that?
#Edit: Why don't I simply add WS_VSCROLL to its static version? Because it has SS_NOTIFY style and I need it to respond to WM_COMMAND messages somehow else. This is why I tried scrolling it manually.
#Update:
Here in both screenshots the text length is the same. When the control is in edit state, its vertical scrollbar is proper. But when it's in static state the vertical scrollbar doesn't match the actual text length. Besides, the scrollbar is always at the same size and same position independent from text length and it's also unscrollable. Why may be the reason of it behaving like this?
#Update: Thanks to #enhzflep's comment, problem is easily solved some other way.

Answer 1

In the interests of removing the question from the Unanswered list, I'll repeat and expand upon one of the comments.
Looking at the images, we can immediately see a clear difference in the way they're each presented. The left image has each line starting with a different character, while the right image always starts with the same character. They also have very differently sized thumbs in the scroll-bar.
Since the problems seem to be stemming from trying to use two different controls to achieve essentially the same task, I'd suggest always using an edit control. (this is the one that appears to behave nicely, and is the one that doesn't wrap the text)
Rather than use two different types of control, I suggest just toggling the read-only flag. With luck (!) the only difference now will be the way mouse and keyboard messages are handled - hopefully you'll get similar behaviour and appearance with such an approach.
The message I'm thinking of that will achieve this is EM_SETREADONLY.
Although the question has been successful answered, I can't find reference in the Microsoft docs to support my theories, thus used language like 'hopefully'.