本文主要是介绍用WM_PAINT解决ListView控件嵌入Edit显示不正常的问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
ListView自带有编辑功能，创建窗口时加上一个style code就可以。但它的编辑功能只能编辑每行第一个元素。
所以只能把Edit控件嵌入到ListView里。这里有两个办法，1是捕捉单击、双击动作，根据点击位置动态显示一个Edit Control。2是直接在每行都设置一个Edit，动态控制各个Edit的位置及其显隐。
我参考了CustomListCtrlDemo，也是把控件嵌入ListView中，也是由程序来控制各个控件的位置及其显隐，从代码能够看出来。并且在拖动滚动条时出现了闪烁现象，也印证了这点。这个Demo截获了若干消息，在消息中刷新控件的位置。由于他用的MFC，而我没用MFC，所以有些他重载的消息函数我没有追到源头。
自己尝试了一下，在各个消息中加入刷新控件位置的处理：WM_MOUSEWHEEL：先刷新控件，位置后发生滚动。这导致控件位置不正确。
WM_NOTIFY：没有捕捉到。
WM_KEYDOWN：先刷新控件，位置后发生滚动。这导致控件位置不正确。
WM_VSCROLL：先刷新控件，位置后发生滚动。这导致控件位置不正确。
有没有哪个消息是处理完滚动才发送的呢？似乎WM_NOTIFY是ListView处理完后发送给父窗口的，但我不想在父窗口来处理ListView内部的控件位置。
或者在消息处理中，把return CallWindowProc(wndproc, hWnd, uMsg, wParam, lParam);提前，把UpdateControl();放到后面去。这样的话就要在UpdateControl()中内置CallWindowProc函数，还要把CallWindowProc的各个参数都传进去，也许还需要进行静态处理，麻烦大了。
最后我灵机一动，ListView总要Paint的吧，我在WM_PAINT里处理。一试成了。虽然这样会加重负担，降低效率。先这样吧。
目前是这样（有一些废注释）：
LRESULT TListView::WndProc(WNDPROC wndproc, HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{switch (uMsg){case WM_NOTIFY:{//NMHDR *pNMHDR = (NMHDR *)lParam;//switch (pNMHDR->code)//{// //拖动和双击都会引起表头宽度的变化//case HDN_BEGINTRACK: //开始拖动列头// UpdateControl();// break;//case HDN_ENDTRACK: //拖动列头// UpdateControl();// break;//case HDN_DIVIDERDBLCLICK: //双击列头// UpdateControl();// break;//}return CallWindowProc(wndproc, hWnd, uMsg, wParam, lParam);}//case LVM_INSERTCOLUMN://case LVM_INSERTITEM://case WM_KEYDOWN:////case WM_MOUSEMOVE://case WM_MOUSEWHEEL://case WM_VSCROLL:case WM_PAINT:UpdateControl();return CallWindowProc(wndproc, hWnd, uMsg, wParam, lParam);}return CallWindowProc(wndproc, hWnd, uMsg, wParam, lParam);
}就一个WM_PAINT起了作用。
这篇关于用WM_PAINT解决ListView控件嵌入Edit显示不正常的问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
