Привет. Что-то не пойму: почему курсорные клавиши нормально перемещают курсор в Memo, когда  Memo лежит на форме приложения, и не работают, когда Memo лежит на форме dll. Т.е. работают только клавиши вверх-вниз, а влево-вправо не обрабатываются, даже обработчик OnKeyDown не вызывается. В чём тут дело?

Ау!

Моржет, кто-то знает решение?

Ау!

Может, кто-то знает решение?

И не только мемо, но едит и т.д., и не только влево-вправо, но и таб. Если только Владимир не поленится разобраться с этим. Я в свое время ковырялся, но не к чему так и не пришел.

Да, mdw, совершенно верно. Такая проблема имела место, когда я писал плагин на чистом WinAPI. Тогда я копал в цикле обработки сообщений, но ничего не добился.

Владимир, помогите нам пожалуйста!

Состряпайте минимальный пример VCL-приложение + memo в dll, как оно по-вашему будет. или достаточно бросить memo на тот пример, что есть в demo?

ОК, Владимир, сейчас сделаю примерчик

Так-так, выяснилились кое-какие подробности. В моём VCL-демо всё работает как надо... А в программе, для которой предназначена моя dll, возникает такая вот дурацкая проблема. Программа написана на сях. Именно в ней и проявляется эта бага с курсорными клавишами. Причём, в VCL-вариантах тех же плагинов, всё работает!

Хорошо, ставим вопрос по другому. Кто знает\подозревает\догадывается, где тут лежат грабли? Может, и г.mdw выскажется по этому поводу? Что-то я не понимаю...

Я открыл DemoModalVCLapp2KOLdll, бросил Memo, запустил. Все стрелки работают.

У меня была проблема со стрелками, когда KOL Panel c контролами из DLL встраивалась в VCL форму. Я так понял что проблема в конфликте двух обработчиках: Application и Applet. Правда почему вверх-вниз работают, а влево-вправо нет??
Я тогда решил проблему использованием VCL:)).

Блин, что же делать? Не охота как-то переделывать под VCL :( Плагин всего в пару сотен строк кода, и на KOL выходит 18 кб всего с упаковкой, а VCL раздует до 150 как минимум, и то с upx-ом... Ладно, решение буду искать по-тихоньку

Наверное, вы не очень внимательно прочитали, что я написал. У вас просто что-то расходится с демой, причем существенно.

Да нет, Владимир, я всё понял. Но дело не в этом. Я же делаю связку VCL+DLL с нуля, и всё работает. Потом гружу только что созданный и проверенный плагин в программу, для которой он предназначен, и всё возвращается к тому, с чего начали - клавиши влево-вправо не работают. Я подозреваю, что дело тут в обработке сообщений с клавиатуры, которую выполняет программа, под которой работает длл-ка. Видимо, эти сообщения уходят куда-то налево. С другой стороны, такой же плагин, написанный на VCL, работает как положено. Такая же ситуация наблюдалась, когда я писал плагин на api, я так и не понял, почему сообщения не доходят. Их просто нет, и всё. Не понимаю...
Это я не к тому, что виноват KOL, вовсе нет, просто такая трабла уже достала порядком...

> Такая же ситуация наблюдалась, когда я писал плагин на api

а какая имеено, как в КОЛ или АПИ?

Вообще-то, если форма из dll вызвана модально, то нужно ОЧЕНЬ постараться, чтобы перехватить сообщения из того цикла обработки сообщений, который запущен в dll. Даже сразу и не придумаешь, как такое СПЕЦИАЛЬНО устроить. Разве что хуками.

Или хот-кеями, вот. Но это по меньшей мере странно, сажать хот-кей на стрелки влево-вправо. Хотя чего в жизни не бывает.

Кстати, обратно хот-кей "отбить" можно как раз хуками. Т.к. в пределах одного приложения, то отдельная dll и глобальный хук не нужен, достаточно в пределах опять же приложения. В хуке можно замещать message на свой, при ловле в своем цикле снова возвращать его в правильное значение.

> а какая имеено, как в КОЛ или АПИ?

Она одна и та же - что в KOL, что в API не работают стрелочки.

> если форма из dll вызвана модально

Нет, там у меня форма рисуется на канве проги, т.е. прога сама вызывает из плагина процедуру, которая сама создаёт окно и прицепляет к родительскому с помощью SetParent. Окно встраивается в программу (а именно так все плагины и работают в этой программе). Затем регулярно вызывает процедуру Draw из плагина, которая перерисовывает окошко.

Бледнолицые любят наступать на грабли! Причем многократно.

> Бледнолицые любят наступать на грабли! Причем многократно.

К чему бы это, мой краснокожий брат?

Тут у нас, все нормально?

function TControl.GetBoundsRect: TRect;
var W: PControl;
   P: TPoint;
begin
  Result := fBoundsRect;
  if fHandle <> 0 then
  begin
     GetWindowRect( fHandle, Result );
     if fIsControl or fIsMDIChild then
     begin
       W := fParent; // WindowedParent;
       if W <> nil then
       begin
         P.x := 0; P.y := 0;
         P := W.Client2Screen( P );
         OffsetRect( Result, -P.x, -P.y );
       end;
     end;
     fBoundsRect := Result;
  end;
end;

Какое отношение имеет  " W := fParent; // WindowedParent;", к новому, чужому, паренту?
И зачем нам "P := W.Client2Screen( P );", координаты старого?
Не в этом ли причина?

===К чему бы это, мой краснокожий брат?
Вопрос поднимался и раньше, я решал подобную проблему средствами АПИ.
А заглянуть в кол, никто не хочет.

> я решал подобную проблему средствами АПИ


Ух ты! А не поделишься рецептом на мыло, али прямо тут? Мне тоже хоца сделать это на апи, ой как хоца!

За подсказку спасибо, гляну...

OK!

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором