Определение компонента, над которым находится курсор мыши.

← →
3asys (2004-03-11 14:15) [0]

Как определить над каким компонентом находится курсор мыши?
В том числе и для компонентов у которых нет события OnMouseMove

С уважением, 3asys

← →
Юрий Зотов © (2004-03-11 14:24) [1]

function ControlUnderMouse: TControl;
var
P: TPoint;
W := TWinControl;
begin
P := Mouse.CursorPos;
W := FindVCLWindow(P);
if W <> nil then
begin
P := W.ScreenToClient(P);
Result := W.ControlAtPos(P, True, True);
if Result = nil then Result := W
end
else Result := nil
end;

← →
NAlexey © (2004-03-11 14:40) [2]

Если мне не изменяет память, то была похожая ветка. Так вот приведенный Юрий Зотов © (11.03.04 14:24) [1] пример сработает невсегда.

← →
3asys (2004-03-11 14:44) [3]

Спасибо Большое! Это работает.
Но мне нужно получить компонент, для того, чтобы затем передать его в качестве родителя при создании на нем нового компонента:

.....
TControl(cmp).Parent:=ControlUnderMouse;
а при этом выдается сообщение: "Incompatible types "TWinControl" and "TControl"
Что здесь можно сделать?

С уважением, 3asys

← →
NAlexey © (2004-03-11 14:46) [4]

Мда, вот тебе бабушка и Юрьев день.:)

← →
Юрий Зотов © (2004-03-11 14:59) [5]

> NAlexey © (11.03.04 14:40) [2]

А в каких же случаях он не сработает? Даже интересно.

> 3asys (11.03.04 14:44) [3]

Вы спрашивали о КОМПОНЕНТЕ под мышью, верно? Не уточняя при этом, что это за компонент, верно? А под мышью может быть ЛЮБОЙ визуальный компонент - то есть, любой потомок TControl.

Именно ТАКОЙ пример я Вам и написал. Эта процедура определяет ЛЮБОЙ контрол, находящийся под мышью - как потомок TWinControl, так и потомок TGraphicControl. А Вам, оказывается, нужны только TWinControl"ы - потому что только они могут быть Parent"ами. Извините, но вопросы надо формулировать точно. А так - что Вы спросили, то Вы и получили, и в том, что Вы спросили не то, что Вам на самом деле нужно - вина Ваша собственная и больше ничья.

Ваша же задача проще.
TControl(Сmp).Parent := FindVCLWindow(Mouse.CursorPos);
И все.

← →
3asys (2004-03-11 15:11) [6]

>>Юрий Зотов
Большое Спасибо - все отлично работает.
Прошу извинить - неудачно сформулировал вопрос.

С уважением, 3asys

← →
Юрий Зотов © (2004-03-11 15:17) [7]

> NAlexey © (11.03.04 14:46) [4]

Ау-у! Так что же там насчет бабушки?
:о)

← →
NAlexey © (2004-03-11 15:22) [8]

Тут я тут.:) Приношу свои извенения, действительно приведенный код работает нормально. В прошлый раз о котором шла речь(NAlexey © (11.03.04 14:40) [2] ) код был несколько другой. И еще сдается мне что мои слова насчет бабушки истолкованы неверно. И к тебе они не относятся никак:) Просто задающий вопрос не был в силах сам разобоаться с тем как воспользоваться кодом.

← →
NAlexey © (2004-03-11 15:30) [9]

Хотя тщательное тестирование всеже показало правоту моих слов. Тест такой:
1)Кладем на форму панель, в нее кладем другую(ну или кнопку там), потом кладем PageControl добавляем одну закладку. Надвигаем PageControl таким образом чтобы он своим краем(именно краем а не TTabShee-тами) наезжал на вложенную панель. Наводим мышь и видим что под мышью у нас не PageControl как должно быть а вложенная в панель панель. Могу впринципе объяснить почему. Такчто...

← →
Юрий Зотов © (2004-03-11 15:36) [10]

Вы имеете в виду, что на панель наезжает правый верхний угол PageControl (т.е. его невидимый кусок)?

Если так, то почему же мы должны получить PageControl? Что видим на экране - то и получаем. Все логично.

← →
NAlexey © (2004-03-11 15:43) [11]

Да, именно это я и имею ввиду. Кстати не такой уж он и невидимый(визуально). С точки зрения интерфейса он очень видимый. И если например делать какой либо дизайнер где таскаешь элементы, этот код будет работать невсегда.

← →
Юрий Зотов © (2004-03-11 15:50) [12]

> NAlexey © (11.03.04 15:43) [11]

> Кстати не такой уж он и невидимый(визуально). С точки зрения
> интерфейса он очень видимый.

То есть, как это? Все же - видимый, или невидимый? Разве есть еще другие варианты?

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

Не понимаю. Давайте говорить конкретно - в каких случаях он НЕ будет работать?

Приведенный Вами случай - не доказательство. Мы видим, что мышь находится над панелью - и функция показывает то же самое. Все нормально.

← →
NAlexey © (2004-03-11 16:25) [13]

>Юрий Зотов © (11.03.04 15:50) [12]
Ок привожу конкретный пример. Почему возникла неодназначность в терминах, и почему я употребил слово визуально. Ключевым моментом здесь является ф-ция
WindowFromPoint The WindowFromPoint function does not retrieve a handle to a hidden or disabled window, even if the point is within the window
В нашем разговоре мы начали употреблять слово невидимый. Пусть будет так. Так вот когда ложишь PageControl поверх панели вложенной в панель(нагляднее на этом фоне смотрелся бы TImage) так вот та часть которая в ремарке этой ф-ции считается невидимой визуально на самом деле видима, и закрывает участок TImage, если например перейти в дизайнер Delphi и потаскать по форме PageControl ясно что он таскается за эту часть, даже если смоделировать приведенный мной пример. Если я завтра захочу написать такой редактор и воспользоваться Вашим кодом то он будет работать(опять же ключевое слово) - НЕВСЕГДА. Вы просили пример, я его привел. В чем дело?

← →
serge35 (2004-03-11 16:59) [14]

Лично я в этом случае делал popup меню и присваивал его к каждой добавленной компоненте. при нажатии на правую кнопку мыши выпадало меню с пунктом "Добавить компоненту" и внутри этого пункта определял компоненту, которая иницилизировала меню.

> NAlexey © (11.03.04 16:25) [13]

> Вы просили пример, я его привел. В чем дело?

В том, что Вы привели пример неверный. И вот почему.

Если Вы будете делать дизайнер, то, как грамотный разработчик, Вы будете обязаны позаботитьсяь о том, чтобы редактируемая форма и все ее компоненты знали о том, что они работают в Design-time (см. SetDesigning и иже с ним). А в этом случае и PageControl, и все другие контролы будут работать не так, как они работаю в run-time, а точно так же, как они работают в самой Delphi (и если они будут работать не так, как они работают в Delphi, то это автоматически означает что дизайнер просто криво написан).

В частности, в этом режиме контролы никогда не будут невидимыми, никогда не будут задизаблены, будут корректно отрабатывать CM_DesignHitTest и другие design-time сообщения (а сам дизайнер обязан позаботиться о том, чтобы такие сообщения посылать или перехватывать - а если он их не посылает или не перехватывает, то это опять-таки просто кривой дизайнер).

И при таком раскладе (то есть, при ГРАМОТНО написанном дизайнере)приведенный мною код тоже сработает нормально и все определит именно так, как Вы и хотите.

Уверяю Вас, что это так. И знаю, о чем говорю - потому что дизайнер я писал. Да и - как Вы считаете, чем пользуется дизайнер самой Delphi?

Ответ - теми же самыми функциями VCL, что использовал и я. Работает ведь? И даже несмотря на FindWindow...

Так что - сорри, но пример Ваш не катит:
"Если я завтра захочу написать такой редактор и воспользоваться Вашим кодом то он будет работать (опять же ключевое слово) - НЕВСЕГДА".

Если Вы завтра захотите написать такой редактор и воспользоваться моим кодом то он будет работать (опять же ключевое слово) - ВСЕГДА.

При условии, что Вы напишете редактор ГРАМОТНО (это тоже ключевое слово). Либо не беритесь писать редакторов.

> И даже несмотря на FindWindow...

Описка, конечно. Имелось в виду WindowFromPoint.

← →
serge35 (2004-03-11 17:43) [17]

Можно привести пример, как перевести компоненту в режим дизайна?

> serge35 (11.03.04 17:43) [17]

Можно - SetDesigning. Но для написания дизайнера этого будет недостаточно. Надо создавать целую СРЕДУ разработки - то есть, целое ОКРУЖЕНИЕ компонента, поддерживающее его редактирование. Так же, как это делает Delphi.

>Юрий Зотов © (11.03.04 17:16) [15]
Извиняюсь за длительное молчание. Не было возможности Вам ответить. Соглашаюсь с Вашими Юрий доводами насчет дизайнера, тем не менее мне кажется что это как раз тот момент когда может быть 2 правды. Может быть пример насчет дизайнера и не совсем удачен, тем не менее, можно придумать массу других примеров в которых возникает необходимость узнавать контрол под мышью, например необходимо выводить ClassName контрола над которым парит мышь вне зависимости от того Enabled он или нет. Я не хотел разжигать спор и проч. Считаю что вы правы, правы по своему. Я бы например посоветовал отказаться от использования WindowFromPoint и использовать рекурсивный перебор контролов сверху вниз, в этом случае не возникло бы такой неодназначности.

Определение компонента, над которым находится курсор мыши. Найти похожие ветки