Проблема: дочерние контролы не реагируют на установку расширенного стиля WS_EX_ACCEPTFILES.

Проблема в сабже. Ситуация следующая: в качестве главного окна программы используется диалоговое окно. Этот диалог содержит некоторое кол-во контролов, в том числе несколько контролов типа Edit которые используются для указания путей к файлам. Я решил реализовать в программе механизм Drag&Drop для упрощения заполнения этих Edit-контролов, но с самого начала столкнулся с проблемами. Дело в том что, не смотря на то, что я установил для Edit-контролов расширенный стиль WS_EX_ACCEPTFILES эти контролы продолжают говорить (с помощью вида курсора) что на них нельзя перетаскивать файлы. Сообщение WM_DROPFILES также не приходит в процедуру окна субклассированных Edit-контролов. В общем, творится что-то не понятное. Так как программка довольно большая, для того чтобы попытаться локализовать проблему я сделал небольшую программку-полигон где с точностью воспроизвел условия и свои действия, и как ни странно там все заработало нормально… В общем, решить проблему не удалось. Помогите, плиз, найти причину проблемы.



З.Ы.: В программе нет вызовов API-функции SetWindowLong c параметром GWL_EXSTYLE, да и шпион MS Spy++ показывает что у Edit-контролов соответствующий стиль установлен.

 

Каким образом установил? Выставляешь флаг в ресурсах — всё работает…

 

IceStudent

Флаг выставляю в рессурсах.

В программке-полигоне у меня тоже все работает нормально, а вот в нужной программе облом...



На всякий случай приаттачиваю исходники проблемной программки (проект для RadASM + MASM32). Нужный файл описания диалога называется FileRepair.dlg. Указанный стиль установлен для двух первых (с верху) Edit-контролов.Сама программка еще не дописана.



1540920143__Problem.rar

 

Проблема ясна: у тебя GroupBox закрывает edit, поэтому нельзя перенести объект на edit.



Всякими SpyXX это не определишь (или определишь, но не сразу), тут помогает утилита, показывающая информацию об окне по курсору мыши (функция WindowFromPoint)…

 

IceStudent

А как можно решить эту проблему, не удаляя GroupBox?

Подскажи, плиз, такую утилитку и где ее можно раздобыть.

 

Вот, поигрался и вышло.

Самому написать. У меня сорцы куда-то подевались, а сама утилита после экспериментов стала слишком страшноватой для общественности…

1627782175__FileRepair.7z

 

IceStudent

Спасибо за помощь!

Опиши, плиз, что именно ты сделал.

 

Эксперименты показывают, что подобные проблемы возникают со всеми контролами созданными после создания GroupBox'а, в пределах которого они располагаются. В то же время проблемы не возникают с теми контролами, которые были созданы до создания соответствующего GroupBox'а. Учитывая это решить проблему можно очень просто: удаляем мешающий контрол GroupBox, предварительно скопировав его в буфер обмена (чтобы не потерять его настройки), и затем вставляем скопированный контрол на форму. Далее перемещаем его на место старого контрола, не забыв по ходу дела переместить все нужные контролы располагающиеся в пределах этого GroupBox’а на передний план.

 

Oleg_SK

Ты сам ответил уже



А вообще, дело в Z-Order'e контролов, который зависит от некоторого свойства (TabIndex), являющегося ничем иным как порядком создания контролов. Т.е. контролы в ресурсах располагаются в порядке TabIndex'a, следовательно, и создаются в этом же порядке.



Тонкость тут в том, что окно, которое было создано позже, располагается (визуально) за окном, которое было создано раньше.

Код (Text):

1.  
2. .data
3.     szEditClass db 'edit',0
4.     szBtnClass  db 'button',0
5.     szBtnText   db 'GroupBoxR',0
6. .code
7. @@:
8.  
9.  
10. invoke CreateWindowEx,WS_EX_CLIENTEDGE or WS_EX_ACCEPTFILES,addr szEditClass,\
11.     NULL,WS_CHILD or WS_VISIBLE or WS_TABSTOP or ES_AUTOHSCROLL,\
12.     20,60,60,21,hWin,0,hInstance,0
13.  
14. invoke CreateWindowEx,0,addr szBtnClass,addr szBtnText,50000007h,10,35,100,61,hWin,0,hInstance,0

Здесь текстовое поле находится перед рамкой, которая уже не мешает перетягивать объекты на текстовое поле.



Т.о., твою проблему можно решить очень просто: выставить для контролов-контейнеров (GroupBox у тебя) значение TabIndex'a большее, чем значение конролов, находящихся внутри контейнеров (edit).

 

IceStudent

Да, что-то я раньше особо не обращал внимания на значение свойства TabIndex, просто считая, что чем позже создан контрол (именно в редакторе, а не в RC-файле) тем ближе к наблюдателю он должен находиться. Во всяком случае, IMHO, так должно быть в соответствии со здравым смыслом, да и в редакторе диалогов в процессе редактирования я вижу именно такой порядок. А теперь оказывается что на самом деле все поставлено с ног на голову, и, следовательно, в процессе редактирования диалога мой взгляд направлен не с переднего плана на задний, а с точностью до наоборот - с заднего на передний... Отсюда и возникла проблема… Мне хотелось бы знать: такое представление диалогов “задом-на-перед” характерно для всех редакторов диалогов, или это особенность редактора RadASM’а ???

 

IceStudent

Хотя проблема уже решена, мне еще не все понятно К примеру, мне не понятно, почему несмотря на то, что Edit был перекрыт контролом GroupBox я видел его, и мог нормально работать с ним? Нормально работала даже кнопка, помещенная в этот Edit. Проблемы возникли только с реализацией механизма Drag&Drop. Честно говоря, в такой ситуации, у меня даже подозрения не возникло о перекрытии Edit’а другим контролом...

 

Отвечу сам себе на вопрос о работе редакторов: глянул сейчас на то, как работают редакторы диалогов в MS VC++ 6.0, Builder'e 5 и Delphi 5, и оказалось, что они делают то же самое. Интересно, почему это так, ведь IMHO это не удобно... Или я чего-то не понимаю?

 

В design-time все эти "Send to back"/"Bring to front" — всего лишь имитация, в ресурсах ничего не меняется (кажется). В run-time ты можешь работать с edit'ом "через" GroupBox, т.к. он так реализован (я пока не в курсе, как именно, через регионы или ещё как).



Возможно, отвечу позже…