Для одного проекта надо сделать разновидность ListView с возможностью редактирования текста во всех ячейках, а не только ячейках первого столбца. Я пробовал создавать первоначально скрытый Edit и по двойному клику мышкой на ячейке ListView показывать его, помещать над этой ячейкой и ставить на него фокус. При прокрутке я двигаю Edit, чтобы он всегда находился над нужной ячейкой. Все вроде работает, только вот Edit иногда налезает на стандартный Header ListView и сидит там, пока Header не перерисуется. Пробовал делать Header всегда "topmost" функцией SetWindowPos и много чего еще пробовал с этой функцией, но ничего не получается. Что делать? 

В таких случаях обычно Edit не держат постоянно, а создают только для редактирования (по клику, нажатию клавиш, etc). Это тем более разумно, что часто редактор для каждого столбца нужен свой. Проблема с "налезанием" на заголовок, возможно, связана с тем, что заголовок находится в клиентской области List View. 
А еще, таблицы с редактированием всех ячеек нет смысла делать на основе List View: чаще всего их делают с нуля. Это только кажется, что готовая функциональность List View помогает, на самом деле она больше мешает...
Посмотри примеры на codeproject, там разных списков\таблиц - выше крыши. 

Я так понял, что контролы там делаются с помощью MFC. А на чистом WinAPI что-нибудь есть (до MFC не дорос)?

PS Да, Header находится в клиентской области ListView. Но я пробовал делать ролителем моего Edit'а и ListView. Все равно ничего не выходит. 

Да в общем, не большая проблема переделать MFC-код на АПИ, по крайней мере то, что касается контролов. Или по крайней мере, посмотреть как сделано, принципы.
Естественно, родителем едита должен быть ListView, кто же еще. Наверно, ты неаккуратно обрабатываешь скролл-сообщения, но в твоем посте недостаточно информации. Возможно,  едит "сползает" со своей ячейки, а возможно, ты ошибочно ставишь едит на ряд, который меньше чем верхний видимый. 
Скажем, ситуация следующая: верхний видимый ряд N 10, в нем текущей является ячейка, скажем, 2я: имеет видимый едит с фокусом ввода и т.д. Пользователь каким-то образом дает команду ScrollDown (например, нажимает соотв. кнопку на скролл-баре). Что произойдет? Теперь верхний видимый ряд 11. А едит по прежнему связан с 10м? Его кто-нибудь переставлял? Я не говорю, что у тебя именно так: просто нужно знать логику, заложенную в управление редактором, вариант-то не один.
 

Как вариант - после утери фокуса редактором прятать его(SW_HIDE). Тогда никуда он не залезет. Отловить правильную позицию после скроллинга поможет позиция первой ячейки сразу после первого отображения listview - она хранит "отступы " - ширину рамки слева и высоту header+ рамка вверху.
Конечно,как сказала Earnest , listview использовать трудно но можно - сделай один раз свой собственный класс и используй дальше в проектах. У меня есть такой, правда производный от MFC-шного CListCtrl 

2_Earnest:

Перемещением Edit'а занимаюсь я, обрабатывая уведомление LVN_ENDSCROLL.

Нет, Edit с ячейки не сползал и всегда находился там, где мне надо, за исключением, конечно, случаев, когда он заползал на заголовок.

Да, я ставил Edit на ячейку, которая при прокрутке уезжала вверх под заголовок. В том и было дело, что я хотел, не производя лишних действий с Edit'ом, заставить его аналогично уезжать под заголовок, а не наползать на последний.

Выход из этой ситуации я нашел очень простой (не знаю, чего я упорствовал с z-order'ом). При прокрутке я получаю номер текущей верхней строки. Если он больше, чем номер строки с Edit'ом, то переставляем Edit куда-нибудь в невидимую область (в своей тестовой программе я использовал следующее: SetWindowPos (hEdit, 0, -100, -100, 0, 0, SWP_NOZORDER). SW_HIDE я не применяю, т.к. в этом случае Edit потерял бы фокус, а заканчиваю редактирование ячейки я как раз при получении сообщения EN_KILLFOCUS от Edit'а (самый легкий вариант).

PS А с контролами на Code Project я обязательно разберусь...

2_threef:

SW_HIDE мне не подходит, как сказано выше.

Теперь к тебе вопрос: разве у ListView есть рамка?

// -----------------------------------------------------------------

На всякий случай, выкладываю код своей тестовой программы. Пожалуйста, сообщите, если найдете в нем ошибки.

  

Это сообщение отредактировал(а) 0x07L - 14.6.2006, 22:20

 
При желании рамка есть у всех. Видимо, threef имел ввиду бордюр, ширина которого зависит от стиля: WS_BORDER, WS_EX_CLIENTEDGE, etc 


Наконец я поняла, чего и как ты хотел сделать. Чтобы эдит "задвигался" по заголовок. Дело в том, что эдит ты создаешь после того как хедер уже создан. И оно, разумеется,сверху. Чтобы задвинуть его вниз попробуй 
SetWindowPos (hWndEdit,HWND_BOTTOM,0,0,0,0,SWP_NOSIZE|SWP_NOMOVE).
Не уверена, что оно "влезет" под заголовок. 

 

Да, именно так. О том, что HWND_BOTTOM ничего не дает, я писал в самом первом посте. Также ничего не дает HWND_TOP для Header'а и помещение Header'а перед Edit'ом. В том и дело.

Да, про такую рамку я чего-то не подумал. Наверное, из-за того, что никогда не приходилось видеть ListView с рамкой.
Спасибо threef.

PS Видимо, я не слишком подробно описал проблему в первом посте. Извините. 

Это сообщение отредактировал(а) 0x07L - 15.6.2006, 10:06

Не заметила, ну да ладно. Все равно это странно. Спаем не смотрел? Действительно едит наверху остается?
Хотя ... кажется где-то попадалась такая ситуация: вверху эдит или внизу, когда в нем фокус - текст спокойно рисуется поверх всего. Выглядит жутко. Если так, то действительно нужно извращаться.
Тем не менее, лучше бы обработку ввода делать не (только) на KillFocus, а писать явную функцию, вызываемую на ряд событий. А Edit прятать (или вообще уничтожать).  Скажем, пользователь нажимает ENTER: видимо, ожидает, что текущий текст будет запомнен в таблице, а фокус перейдет на ячейку вниз. Нажатие стрелок вних-вверх-вправо-влево - аналогично. Нажатие ESCAPE - замена введенного текста старым значением и отказ от редактирования.
Кроме того, если эдит заново создавать для каждой ячейки, можно менять его тип в зависимости от типа ячейки (где-то это может быть выпадающий список и т.д.).
В общем, сколько я не видела реализаций таблиц - никогда редактор по ячейкам не ездил, а всегда создавался-уничтожался. Наверное, не зря. 

Просто это было скрыто за формулировкой


Это просто тестовая программа, а не реальное приложение. В последнем случае, полностью согласен, обработки EN_KILLFOCUS совершенно недостаточно.


Честно говоря, я не знаю, как Spy'ем определять z-order. Могу только сказать, что в списке окон Edit стоит выше Header'а.
А если посмотреть свойства окна ListView, то его "First Child Window" - это Edit. 

Так и смотреть. Я, честно говоря, тоже всегда забываю - первое окно - это первое по z-порядку или последнее. Всегда проверяю: вариантов-то всего 2. насчет "посмотреть Спаем" я имела ввиду - меняется что-нибудь от применения SetWindowPos или нет.
Но раз не помогает, то и ладно.