Здравствуйте!
Как определить итем в CTreeCtrl, на котором нажали правую кнопку мыши.

Я думал нужно HTREEITEM hItem=m_Tree.GetSelectedItem(), но это не проходит.
Нужно как-то определить итем, на котором нажали правую кнопку,потом его выделить, а потом использовать GetSelectedItem().
Как?

Лови либо WM_RBUTTONDOWN, либо уведомление NM_RCLICK. Вызывай HitTest, чтобы определить, какой итем кликнули, потом делай ему SelectItem.

Спасибо за ответ.


Я пробовал так:
определял положение курсора:


вызывал функцию:



но почему-то она возвращает NULL. Какие флаги нужно указывать для этой функции? Или что-то я делал не так?

Нужно предварительно перевести координаты курсора (экранные) в клиентские:
ScreenToClient()

Спасибо, Earnest !
ScreenToClient() помогло!
Я, полазив по форумам, пытался сделать вот так:

Но MessageBox выводил пустую строку. 
А вот по двойному клику левой кнопки работает нормально:

В чём причина?

1) В моем MSDN написано, что на NM_RCLICK дереву приходит простой NMHDR, а вовсе не NMTREVIEW, так что скорее всего, а hItem у тебя лажа. Врочем, сам отладчиком посмотри. Нужно спрашивать позицию курсора и вызывать HitTest.

2) По правому клику, по-умолчанию, итем не получает фокус, а по левому - получает.

Спасибо, Earnest, за ответы!
Вопрос решён. 

Похожая ситуация, только нужно отследить итем, на крестик которого пользователь нажал левой кнопкой.
Выделять при этом итем не нужно, а нужно получить его текст.
Посоветовали TVN_ITEMEXPANDED.//СОБЫТИЕ РАЗВОРОТА УЗЛА

А как из него можно вытащить нужную инфу.
Или не парится а попробовать выше описанный метод?

Сделал вот так


Только 
HTREEITEM item = pTree->HitTest(pt);
через раз возвращает не верные итемы.
Например щелкая на "Мои Документы",  возвращает вложенный в мои документы узел "Documents and Settings".
А например с диском G или H  - все корректно

В чем может быть проблема.
И как различить развернут узел или нет.

Еще, я заполняю дерево постепенно: нажал на узел заполнил  его детей первым уровнем иерархии. А как потом избежать повторного заполнения после того как свернул и снова развернул узел?

Это сообщение отредактировал(а) CityAC - 4.4.2007, 14:19

В MSDN все написано:

Т.е. 

Насчет состояния - смотри pnmtv->action, или можно тупо спросить GetItemState (hItem, TVIS_EXPANDED)

И убедись, что обработчик повешен на TVN_ITEMEXPANDED, а не на TVN_ITEMEXPANDING.

Если определять итем по координатам курсора, то как раз обработчик нужно вешать на TVN_ITEMEXPANDING, 
т.е. нужно получить итем под курсором до того как ветка развернется, иначе, если ветка окажется большая и будет иметь место скроллинг, 
то после развертки ветки под курсором окажется другой итем. Что собственно и происходило у меня когда обрабатывалось TVN_ITEMEXPANDED.

если же так как Вы, уважаемая Earnest, предложили в пред. посте то помоему все равно на какой обработчик. у меня по крайней мере на TVN_ITEMEXPANDING работает. Но я в отличие от Вас могу не знать каких то нюансов.

А можно ли к вставляемому узлу добавить свою информацию.
В частности мне нужно к узлу добавить информацию что я его уже заполнял чтобы при следующем открытии не заполнять его повторно.

Это сообщение отредактировал(а) CityAC - 4.4.2007, 17:08

А просто спросить, есть ли у узла дети - не достаточно (ItemHasChildren)?
Но если нужна своя информация - то есть lParam в каждом итеме, он для того и предназначен.

Это зависит от задачи. Если требуется предваряющее действие, да еще и с возможностью отказаться - то OnExpanding, если post-обработка - то OnExpanded (скажем, заменить картинку). Во всяком случае, во время OnExpanded ты можешь точно спросить item, раскрыт ли он, и получишь правильный ответ.
А если ты их заполняешь - то пожалуй, да, нужно на OnExpanding.
Только у меня вызывает сомнение сам факт заполнения при раскрытии. Зачем?

А когда в таком случае заполнять узел детьми?

А сразу никак? При создании. Или при каком-то событии, когда узнаешь, что дерево нужно перестроить.
Если элементов немного (сотня-две) это довольно быстро делается. Только до и после поставь скобки SetRedraw(FALSE\TRUE), чтобы в процессе добавления итемов не моргало.

Я изучаю дерево пытаясь создать проводник. Можешь представить сколько у меня узлов нужно загрузить при создании.
Я отказался от идеи загрузки при создании после того как просидел 1 минуту пока отработали все рекурсии.

У меня корявый код, но он работает.
можно прислать на разбор?

Наверное все же основное время занимает прохождение по файловой системе (а то и по удаленным компам)...
Я бы отделила построение дерева файлов от заполнения дерева-контрола. Скажем, построение файлового дерева засунуть в поток, построение удаленных веток действительно отложить on-demand, пока не понадобятся, а контрол обновлять, ну скажем по таймеру, пока изменения не прекратяться.
Это и с точки зрения дизайна лучше: разные задачи - разный код, и гибче.


Нет, извини, код твой смотреть не буду, это слишком много времени съест. Но если есть желание, почему бы не выложить, может народ что посоветует.

Есть ли возможность в узле дерева хранить полный путь к нему?

О каком дереве ты говоришь? Если о TreeCtrl, то это никому не нужно - путь легко восстанавливается посхождением вверх - по парентам. Если о собственной структуре - то же самое. Типичный узел дерева кроме ссылок на  потомков обычно хранит ссылку на парента, по которым и можно восстановить весь путь.
Хранение всего пути в каждом узле явно избыточно и мешает гибкости. Например, при перемещении узла по дереву ...

Да я так и реализовывал, но думал что есть возможность хранить весь путь

Возможность есть, но нет необходимости. Если все же уж очень приспичит то SetItemData(HTREEITEM hItem, DWORD_PTR dwData); Передашь указатель на сроку с полным путем.

Только эти указатели кто-то менеджить должен (создавать, хранить, уничтожать) - дерево за тебя это делать не будет.

Всем спасибо!!!
Более менее разобрался
Хранить полное имя действительно нет необходимости
получал имя узла так