Вызов процедуры из EXE...

XxLEVxX

А не, всё нормально, это я в вакууме.. почемуто думал не про переменную, а про Eax

 

XxLEVxX

Разжевать и в рот положить ?
Если достаточно передать два целочисленных параметра (например код клавиши + id процесса), то можно использовать любое юзерское сообщение и слать его через PostThreadMessage главному потоку своего ехе или через PostMessage окну формы, и соотв-но отлавливать его в обработчике Application.OnMessage своей дельфийской проги. Номер используемого сообщения (что-то типа $BEEF), а также id потока или хэндл окна передаешь из ехе в dll при установке хука.
Если нужно передавать более двух параметров, то можно юзать SendMessage c WM_COPYDATA

 

Вот этого не требуется!
А за все остольное ОГРОМНОЕ СПАСИБО!!!
Буду копаться.

 

leo

Лучше всё же не любое, а полученное через RegisterWindowMessage. Не знаю, как сейчас, а раньше хватало всяких "управлялок винампом", которые не заморачивались перебором и проверкой всех окон, а просто выблёвывали WM_USER+... по адресу HWND_BROADCAST и делали вид, что так и надо.

 

Теперь понятно, что таким способом:

Код (Text):

1. invoke FindWindow,0, addr nEXE
2. invoke PostMessage,eax,WM_QUIT,0,0

Я закрываю дельфийскую прогу из dll.
А если будет так : invoke PostMessage,eax,0,vCODE,0
(простите меня за глупый вопрос)
Как мне сохранить параметр vCODE в дельфийской программе?

 

Сказал же уже - см. в справке событие TApplication.OnMessage

 

Уважаемый leo в справке я нашел только это:

Код (Text):

1. procedure TForm1.FormCreate(Sender: TObject);
2.  
3. begin
4.   Application.OnMessage := AppMessage;
5. end;
6.  
7. procedure TForm1.AppMessage(var Msg: TMsg; var Handled: Boolean);
8. begin
9.   if Msg.message = WM_FILEREADY then
10.   begin
11.     Memo1.Lines.LoadFromFile(StrPas(PChar(Msg.lParam)));
12.     Handled := True;
13.  
14.   end;
15.  
16.   { for all other messages, Handled remains False }
17.   { so that other message handlers can respond }
18. end;

Пытался разобраться, ноо... толи руки кривые....
При выполнении данной строки вылетает ошибка
begin
Application.OnMessage := AppMessage;
end;

Прошу помогите разобраться...

 

То ли голова пустая...
Небось процедуру AppMessage в описание формы не "догадался" добавить:

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

 

leo

Оно бы тогда даже не откомпилировалось. Да и работает этот OnMessage через толстую прослойку, в которую мало ли чего может быть напихано. Я для такого дела на WinAPI создавал пустое невидимое окно и в нём ловил сообщения, как моей душе было угодно. Подходящий и почти готовый цодес, наверное, даже из Яндекса уже можно срисовать.

 

А "оно" и так не откомпилировалось, т.к. в рантайме на таком элементарном присваивании никакой ошибки быть не может

Нормально он работает, и прослойка "тончайшая" (по одной две строчки в HandleMesage и ProceccMessage), а если постить сообщение окну, то прослойка будет намного больше Ну а если сендить, то ваще труба с бесполезными переключениями потоков туда-обратно

 

leo
БОЛЬШОЕ, БОЛЬШОЕ СПАСИБО!!!
Разобрался, прогу почти накатал, работает как часы ) Очень доволен, что удалось реализовать идею данным способом!

Да, нужно бы...

Тут еще один вопросик возник.
Как можно внести изменения в прогу?
Т.е. Открыл я свою прогу, там у меня Edit'ы вношу нужные мне данные, нажимаю на кнопочку и при следующем старте программы эти данные используются программой.
P.S.Прошу не предлагать использование дополнительного файла(txt/ini) в который можно вносить настройки. Лишний груз тоскать не охото.

 

XxLEVxX

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

НО! Идея это ИМХО крайне неудачная. Вам оно надо, чтобы при каждом запуске проактивка пугала пользователя изменённым хешем образа? ИМХО лучший вариант хранить настройки — в ini-файле, лежащем в одной папке с программой, т.к. это даёт возможность отложить файл с настройками в надёжную папочку и подменять его в любой момент. В том числе использовать старый файл настроек с новой версией программы. Кроме того ini файл даёт гибкость в выборе его размещения. А в случае хранения настроек в собственном образе может возникнуть безвыходный облом в случае, если доступ на запись в него ограничен политиками безопасности системы.
К тому же адекватные пользователи любят быть в курсе, куда программа суёт свой нос. Поэтому, например, запись в реестр — также далеко не лучшая альтернатива.

В общем несмотря на P.S. описаный в нём вариант и есть самый удачный равно как и простейший.

 

leo

А ещё - невидимое окно, как обязательная принадлежность TApplication.

Точно такая же, только окно будет полностью своё, а не разделяемое с VCL для её нужд.

 

l_inc
Вы меня правильно поняли.
Спасибо! Учту

 

CyberManiac
Причем тут вообще окна ?
Application.OnMessage вызывается непосредственно из цикла выборки сообщений перед Translate\Dispatch и соотв-но может перехватывать как сообщения любым окнам ДО их передачи в процедуру окна (=> прослойка точно меньше ), так и сообщения потоку (PostThreadMessage), вообще не привязанные к какому-либо окну