Работа с MainMenu "чужого" приложения.

← →
Leshiy © (2006-12-05 12:34) [0]

Здравствуйте мастера.
Есть задача - расшить возможности некого приложения.
Операция по внедрению подопытному блокноту в меню "своего" пункта прошла успешно (Блокнот - жив, здоров).
А вот с приложением, для которого все это нужно, все немного сложнее.
Дело в том, что в этом приложении, главное меню лежит на ActionMainMenuBar.
До самой панельки я добрался, а вот до меню - не получается.

Помогите "добраться" до главного меню приложения.

← →
GrayFace © (2006-12-05 13:05) [1]

Если пишешь на той же версии Дельфи, то с помощью FindControl можно получить контрол и работать как со воим. Но есть 2 проблемы:
1) Чтобы FindControl работал, надо чтобы совпадали ControlAtomString, а он формируется с использованием hInstance. Так что надо перед инициализацией Controls его менять на GetModuleHandle(0) и восстанавливать после инициализации Controls. Дома смогу подробнее написать.
2) Строки. Удалять строки должен тот же MemoryManager, что создавал. Самое простое, наверное, - это увеличить счетчик ссылок своих строк, чтобы их не удаляли.
pocedure AddRef(s:string); var s1:string; begin s1:=s; pointer(s1):=nil; end;

← →
Leshiy © (2006-12-05 13:19) [2]

GrayFace © (05.12.06 13:05) [1]
Если пишешь на той же версии Дельфи, то с помощью FindControl можно получить контрол и работать как со воим.
Нет, приложение без исходников, в виде готового exe-шника.

← →
GrayFace © (2006-12-05 17:43) [3]

Ну ActionMainMenuBar есть только начиная с D6, насколько я знаю, так что вариантов не много. Надо внедряемую dll писать на той же версии, на которой сделан exe, чтобы проблем не было.

← →
Leonid Troyanovsky © (2006-12-05 17:52) [4]

> Leshiy © (05.12.06 12:34)

> Помогите "добраться" до главного меню приложения.

WinSight32 (Spy++ & etc) - тебе в руки.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-12-05 17:59) [5]

> GrayFace © (05.12.06 13:05) [1]
> Если пишешь на той же версии Дельфи, то с помощью FindControl
> можно получить контрол и работать как со воим. Но есть 2
> проблемы:

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

Мораль: предлагаемый подход может сработать в весьма ограниченных
случаях.

С другой стороны, внедрение хука, сабклассирование окон и т.п.
win32 only - вполне достижимая (хотя, и весьма трудоемкая) цель.

--
Regards, LVT.

← →
Leshiy © (2006-12-05 18:50) [6]

GrayFace © (05.12.06 17:43) [3]
Или я тебя не понимаю, или ты меня.
Причем здесь
Ну ActionMainMenuBar есть только начиная с D6,...
Мне нужно, средствами WinAPI, добраться до меню.
А с его модификацией и отловом нажатия на мой пункт, я думаю, проблем не возникнет.

Leonid Troyanovsky © (05.12.06 17:52) [4]
WinSight32 (Spy++ & etc) - тебе в руки.
Посмотрел. Ничего нового (по сравнению с прогой собранной по примерам из статей, которая показывает все контролы приложения) не увидел, ну показывают они сообщения, толку от которых практически никакого.

з.ы.
Leonid Troyanovsky © (05.12.06 17:59) [5]
Если все так плохо, то есть еще ToolBar этого Action"а.
Завтра попробую кнопку ему "вживить".

← →
Leonid Troyanovsky © (2006-12-05 19:39) [7]

> WinSight32 (Spy++ & etc) - тебе в руки.
> Посмотрел. Ничего нового (по сравнению с прогой собранной
> по примерам из статей, которая показывает все контролы приложения)
> не увидел, ну показывают они сообщения,

Зачем сообщения?
Нужное меню он идентифицирует? Класс, парент и т.д.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-12-05 19:45) [8]

> Leshiy © (05.12.06 18:50) [6]

> Если все так плохо, то есть еще ToolBar этого Action"а.

Ничего плохого (как, впрочем, и хорошего) мы пока не видели.
И не нужны никакие ToolBar, нужно идентифицировать окно
как Tool Bar, т.е., его класс, способность воспринимать
сообщения TB_*, его хендл, наконец.

И работать с win32 only. msdn тебе в руки.

--
Regards, LVT.

← →
GrayFace © (2006-12-06 14:51) [9]

Leonid Troyanovsky © (05.12.06 17:59) [5]
> Проблем гораздо больше, и здесь они не раз обсуждались.
> Не вижу смысла возобновлять оные малоплодотворные дискуссии.
>
>
> Мораль: предлагаемый подход может сработать в весьма ограниченных
> случаях.

Нет. Проблем мало. На ум приходят только 2 вышеперечисленные, но могут возникнуть по ходу. Объясню сам метод:
1) Берем любой пункт меню, узнаем его класс.
2) Создаем контрол этого класса на меню.
3) Если хотим ему задать название, извращаемся, как я написал (еще можно поискать в чужой exe метод, работающий со строками, типа SetString).
Т.е. это не "форма в dll" и тамоших минусов здесь нет.

Leshiy © (05.12.06 18:50) [6]
> Мне нужно, средствами WinAPI, добраться до меню.
> А с его модификацией и отловом нажатия на мой пункт, я думаю,
> проблем не возникнет.

Добраться до меню можно без проблем, посмотрев Spy++. Еще можно через FindComponent, если пользоваться моим способом.
А вот добавить пункт голым WinAPI едва ли возможно.

← →
Leonid Troyanovsky © (2006-12-06 19:56) [10]

> GrayFace © (06.12.06 14:51) [9]

> > Мораль: предлагаемый подход может сработать в весьма ограниченных
> > случаях.

> Нет. Проблем мало. На ум приходят только 2 вышеперечисленные,
> но могут возникнуть по ходу. Объясню сам метод:

Начинать надо с того, что непосредственно сама FindControl в
библиотеке неприменима.
Конечно, сделать ейный работоспособный аналог не проблема. Однако,
при попытках полезно применить искомое нас ждет та самая "форма в длл".

--
Regards, LVT.

> Leonid Troyanovsky

А что если накрыть поверх существующего меню свою формочку с аналогичным меню, да так чтоб эта форма оставалась на месте при любом резайце?

> Elen © (07.12.06 08:46) [11]

> А что если накрыть поверх существующего меню свою формочку
> с аналогичным меню, да так чтоб эта форма оставалась на
> месте при любом резайце?

Если б мне пришлось делать подобное, то я вставлял бы не в
это неуловимое меню, а в более доступные места, скажем, в
system menu. Или, как предполагал автор в [6]- добавить
кнопку на тулбар со своим действием.

--
Regards, LVT.

Leonid Troyanovsky © (06.12.06 19:56) [10]
Начинать надо с того, что непосредственно сама FindControl в
библиотеке неприменима.

При определенных извращеньях применима:
library Dll; uses SysUtils, Classes, RSDllForm1, // Меняет hInstance на hInstance приложения Forms, RSDllForm, // Восстанавливает настоящий hInstance Graphics, Unit3 in "Unit3.pas" {Form1}; unit RSDllForm1; interface uses Windows, SysUtils, Classes; var RealHInstance:LongWord; implementation initialization RealHInstance:=HInstance; HInstance:=GetModuleHandle(nil); end. unit RSDllForm; interface uses Classes, Windows, RSDllForm1, Forms; implementation initialization HInstance:=RealHInstance; end.
Я смотрел инициализацию модулей в D7 - hInstance в тех, которые это затрагивает используется только в одном месте - при генерации ControlAtom и ControlAtomString.

Альтернативное решение, с меньшим извращеньем:

function ObjectFromHWnd(Handle: HWnd): TWinControl; var OwningProcess: DWORD; begin if (GetWindowThreadProcessID(Handle, OwningProcess) <> 0) and (OwningProcess = GetCurrentProcessID) then Result := Pointer(SendMessage(Handle, RM_GetObjectInstance, 0, 0)) else Result := nil; end; initialization ControlAtomString := Format("ControlOfs%.8X%.8X", [GetModuleHandle(0), GetCurrentThreadID]); RM_GetObjectInstance := RegisterWindowMessage(PChar(ControlAtomString));
Только строка ControlAtomString := Format("ControlOfs%.8X%.8X", [GetModuleHandle(0), GetCurrentThreadID]); зависит от версии Дельфи. См. Controls.pas

Этот способ здесь случае лучше.

Elen © (07.12.06 8:46) [11]
А что если накрыть поверх существующего меню свою формочку с аналогичным меню, да так чтоб эта форма оставалась на месте при любом резайце?
Сложно, да и проблемы формы в dll.

> Сложно, да и проблемы формы в dll.

А че только из ДЛЛ? Мне пришлось наподобие такого делать - прога в таймере выставляла окошко поверх чужего меню. В принципе работало без тормозов с интервалом в 100

8-\ Да уж.

Работа с MainMenu "чужого" приложения. Найти похожие ветки