Здравствуйте, CR-LF, Вы писали:

>> Я бы сначала посоветовал почитать ветку где обговаривается почему нельзя
>> использовать FindWindow для
>>поиска уже запущеной програмы
CL>Оп-п-паньки !!!
CL>А что тогда ? — Использовать FindWindow для поиска незапущенных программ ?!
Просто если критерием запущенности программы считать созданное окно, то у нас могут быть накладки. Поэтому рекомендуется пользоваться обьектами синхронизации в паре с FindWindow

>> Если вкратце в двух словах, то просто мы не сможем гарантировать то что мы
>> быстренько накликали на
>>запуск програмы, а она успела создать нужное окно.
CL>Так я же ищу первую копию, которая была создана давно.
В основном работать будет. Но где гарантия что вы сделали два DblClik по иконке запуска

>>
>> Для этого правильно использовать обьекты синхронизации, например мютексы —
>> CreateMutex.
>> Пример я закидывал давным давно
>> здесь<br />
<span class='lineQuote level2'>&gt;&gt;</span>

Автор: Danchik
Дата: 09.08.05

CL>Да уж ;(
CL>Очень просто ...
Очень просто только в одно место ходят
Я предложил целый работающий юнит, ваше дело пользоваться ли им или нет. Есть еще реализация от Jedi Code Library — JclAppInst.pas. Ту вообще все очень просто. Смотрите как пишут люди и разбирайтесь зачем. Если лень — пользуйтесь готовым.

Здравствуйте, Danchik, Вы писали:

D>Да потому что начиная с Win2k SetForegroundWindow перестал работать как ожидалось.

Она работает, как и обещано.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/allowsetforegroundwindow.asp

Т.е., если запускаемое приложение — foreground (а оно и будет таковым, если
его пускает _юзер_: из проводника, командной строки, ярлыка и т.п.),
то оно имеет полное право сделать из требуемого приложения foreground
без всяких ухищрений. Ну, а в противном случае это и не нужно.

Здравствуйте, Leonid Troyanovsky, Вы писали:

CL>> SendMessage(hndl,WM_RESTOREFROMTRAY,0,0);

LT> Это выглядит подозрительно. В соответствие с политикой MS
LT> non-foreground процесс не может стать foreground по своей воле,
LT> а токмо волей foreground процесса.

Тогда — PostMessage ?


Вообще мне нравится unix way — в обговоренном месте создается файлик — либо где зранится PID, либо файл-сокет (аналог Named Pipes).
Вторая прога при старте проверяет существование этого файла, потом или существование процесса с нужным номером и что неомер не reused, а именно другой экземпляр той же проги (напр. откликается на нужные сообщения), или проверяет что сокет открыт и на другом конце дают правлиьный отзыв

Здравствуйте, Аноним, Вы писали:

CL>>> SendMessage(hndl,WM_RESTOREFROMTRAY,0,0);

LT>> Это выглядит подозрительно. В соответствие с политикой MS
LT>> non-foreground процесс не может стать foreground по своей воле,
LT>> а токмо волей foreground процесса.

А>Тогда — PostMessage ?

Во-первых, как видно из других сообщений, обработчик WM_RESTOREFROMTRAY ничего противозаконного не делает, в .т.ч. не пытается сделать свое окно foreground-ным. Ну а во-вторых есть AllowSetForegroundWindow.

Здравствуйте, CR-LF, Вы писали:

CL>SendMessage(hndl,WM_RESTOREFROMTRAY,0,0);
CL>SetForegroundWindow(hndl);

CL>все же не то ?

В этом случае сообщение посылается окну приложения.
Менять его оконную процедуру не очень удобно.
С другой стороны, как здесь уже заметили, обработчик
не делает ничего преступного, т.е. можно ограничиться
обработчиком Application.OnMessage, а сообщение посылать
путем PostThreadMessage(tid, WM_RESTOREFROMTRAY, 0, 0),
где tid определяем через GetWindowThreadProcessId.

Т.е.,

SetForegroundWindow(hndl);
PostThreadMessage();

Здравствуйте, Аноним, Вы писали:

А>Тогда — PostMessage ?

В данном случае, получается, что, действительно, Post.

А>Вообще мне нравится unix way — в обговоренном месте создается файлик — либо где зранится PID, либо файл-сокет (аналог Named Pipes).

В Windows самый простой способ сделать подобное — именованный file mapping,
связанный не с реальным файлом, а с системным свопом.

А>>Вообще мне нравится unix way — в обговоренном месте создается файлик — либо где зранится PID, либо файл-сокет (аналог Named Pipes).

LT> В Windows самый простой способ сделать подобное — именованный file mapping,
LT> связанный не с реальным файлом, а с системным свопом.

А как потом IPC организовывать ?

С NAmed Pipes понятно.
Если в файл класть Thread ID — то PostThreadMessage.

Удаление файла, если процесс упал не удалив файл, мне кажется проще, чем удаление совместно используемого (пусть и крайне недолго) свопа.

Впрочем, кроме файла ,можно еще в реестре что-нибуждь записать, где-нибудь в DYN DATA

Здравствуйте, Аноним, Вы писали:

LT>> В Windows самый простой способ сделать подобное — именованный file mapping,
LT>> связанный не с реальным файлом, а с системным свопом.

А>А как потом IPC организовывать ?

Если нужен полноценный r/w, то нужен еще один (именованный) объект — мьютекс,
который будет отвечать за доступ. Т.е., процессы должны начинать ч/з с захвата
мьютекса, а заканчивать — release.

А>Удаление файла, если процесс упал не удалив файл, мне кажется проще, чем удаление совместно используемого (пусть и крайне недолго) свопа.

Ничего удалять и не надо. Т.е., система удалит маппинг, когда будет закрыт
последний его открытый хендл (с учетом UnMapViewOfFile).
Другими словами, то, что такой маппинг проецируется на системный своп —
забота системы. В жизни может быть так, что данные в своп и не попадут.

> CL>SendMessage(hndl,WM_RESTOREFROMTRAY,0,0);
> CL>SetForegroundWindow(hndl);
>
> CL>все же не то ?
>
> В этом случае сообщение посылается окну приложения.
> Менять его оконную процедуру не очень удобно.
Не понял...
Кто собирался менять оконную процедуру ?

> С другой стороны, как здесь уже заметили, обработчик
> не делает ничего преступного, т.е. можно ограничиться
> обработчиком Application.OnMessage,
Дык, а чем плохо-то, если у меня этим занимается форма ?
Тем более, что форма ловит только WM_RESTOREFROMTRAY, а
Application.OnMessage — вообще все приходящие сообщения.

>а сообщение посылать
> путем PostThreadMessage(tid, WM_RESTOREFROMTRAY, 0, 0),
> где tid определяем через GetWindowThreadProcessId.
>
> Т.е.,
>
> SetForegroundWindow(hndl);
> PostThreadMessage();
Совсем меня запутали:
SendMessage, PostMessage, PostThreadMessage
Какая разница-то в данном случае ?
Почему PostThreadMessage надо после SetForegroundWindow ?

Здравствуйте, CR-LF, Вы писали:

CL>Кто собирался менять оконную процедуру ?

А как ты собирался обрабатывать сообщение WM_RESTOREFROMTRAY?

CL>Дык, а чем плохо-то, если у меня этим занимается форма ?
CL>Тем более, что форма ловит только WM_RESTOREFROMTRAY, а
CL>Application.OnMessage — вообще все приходящие сообщения.

Во-первых, не все, а только которые Post.
Во-вторых, какое отношение имеет форма к сообщению
посланному окну приложения.

CL>SendMessage, PostMessage, PostThreadMessage
CL>Какая разница-то в данном случае ?

RTFM: SendMessage, PostMessage, PostThreadMessage

CL>Почему PostThreadMessage надо после SetForegroundWindow ?

Чтобы первая копия стала foreground, и обрабатывала сообщение
уже в этом качестве.

> CL>Кто собирался менять оконную процедуру ?
>
> А как ты собирался обрабатывать сообщение WM_RESTOREFROMTRAY?
Ну я же показывал:

TMyForm = class(TForm)
    ....
    procedure WMRestoreFtomTray(var Message: TMessage); message 
WM_RESTOREFROMTRAY;
end;

Или в результате компиляции этого кода изменится оконная процедура
приложения ?
Ну и что, собс-сно, если и так ?

> CL>Дык, а чем плохо-то, если у меня этим занимается форма ?
> CL>Тем более, что форма ловит только WM_RESTOREFROMTRAY, а
> CL>Application.OnMessage — вообще все приходящие сообщения.
>
> Во-первых, не все, а только которые Post.
Что значит 'которые Post' ?

> Во-вторых, какое отношение имеет форма к сообщению
> посланному окну приложения.
А главная форма не окно приложения ?

> CL>SendMessage, PostMessage, PostThreadMessage
> CL>Какая разница-то в данном случае ?
>
> RTFM: SendMessage, PostMessage, PostThreadMessage
Ну читал я: SendMessage посылает сообщение и ждет, когда оно будет
обработано.
PostXXXX посылает и не ждет.
А вот какая разница в данном случае между PostMessage и PostThreadMessage
ваще непонятно:
PostMessage посылает сообщение в очередь потока, который создал указанное
окно...
PostThreadMessage посылает сообщение в очередь потока, который нам предстоит
определить с помощью GetWindowThreadProcessId.
GetWindowThreadProcessId получает идентификатор процесса, который создал
указанное окно.
Замкнутый круг, однако.

> CL>Почему PostThreadMessage надо после SetForegroundWindow ?
>
> Чтобы первая копия стала foreground, и обрабатывала сообщение
> уже в этом качестве.
А она (первая копия) знает в каком она качестве находится ?
И есть ли ей разница в каком качестве обрабатывать сообщение ?

А>>А как потом IPC организовывать ?

LT>Если нужен полноценный r/w, то нужен еще один (именованный) объект — мьютекс,

...и описанная ниже ручная работа

А мьютексы могут конфликтовать по имени с другими программами, особенно компонентно написанными на Delphi (Mutex1, Mutex2 ии т.д.

А>>Удаление файла, если процесс упал не удалив файл, мне кажется проще, чем удаление совместно используемого (пусть и крайне недолго) свопа.

LT> Ничего удалять и не надо. Т.е., система удалит маппинг, когда будет закрыт
LT> последний его открытый хендл (с учетом UnMapViewOfFile).

Я боюсь что он может оказаться октрыт не только основной программой.
Хотя.. в случае SHARE_DENY_ALL это вряд ли.

Ну, видимо, дело вкуса

Здравствуйте, CR-LF, Вы писали:

CL>Или в результате компиляции этого кода изменится оконная процедура
CL>приложения ?

Не должнa IMHO.

>> Во-первых, не все, а только которые Post.
CL>Что значит 'которые Post' ?

То что не те, которые Send.
Send проходят мимо очереди — прямым вызовом оконной процедуры.
Соотв. при этом возхникает (по крайней мере гипотетически) возможность проверять foreground-ли окно отправившее сообщение, права доступа и прочую фигню. Например процессы могут устроить друг другу deadlock

>> Во-вторых, какое отношение имеет форма к сообщению
>> посланному окну приложения.
CL>А главная форма не окно приложения ?

Ни в коем случае!!!

Иначе бы Application.Title == Application.MainForm.Caption


CL>Ну читал я: SendMessage посылает сообщение и ждет, когда оно будет
CL>обработано.

не послыает оно его, на самом деле, примерно как в VCL метод .Perform

CL>PostMessage посылает сообщение в очередь потока, который создал указанное
CL>окно...
CL>PostThreadMessage посылает сообщение в очередь потока, который нам предстоит
CL>определить с помощью GetWindowThreadProcessId.

CL>Замкнутый круг, однако.

Нет. У одного потока может быть 100 окон.

>>> Во-первых, не все, а только которые Post.
> CL>Что значит 'которые Post' ?
>
> То что не те, которые Send.
> Send проходят мимо очереди — прямым вызовом оконной процедуры.
> Соотв. при этом возхникает (по крайней мере гипотетически) возможность
> проверять foreground-ли окно
>отправившее сообщение, права доступа и прочую фигню.
А собственно, какая разница первой копии, кто послал ей сообщение ?
Foreground не-foreground.
Че, если не-foreground, то уже и сообщения посылать не моги ?
И какие для этого права нужны ?

>>> Во-вторых, какое отношение имеет форма к сообщению
>>> посланному окну приложения.
> CL>А главная форма не окно приложения ?
>
> Ни в коем случае!!!
Ну хорошо, форма — не окно приложения.
Но она же ловит WM_RESTOREFROMTRAY.

> CL>PostMessage посылает сообщение в очередь потока, который создал
> указанное
> CL>окно...
> CL>PostThreadMessage посылает сообщение в очередь потока, который нам
> предстоит
> CL>определить с помощью GetWindowThreadProcessId.
>
> CL>Замкнутый круг, однако.
>
> Нет. У одного потока может быть 100 окон.
Блин, я самый тупой на этом форуме
Ну и что, что 100 окон ?
Какому бы из них я не посылал сообщение, поток-получатель-то один.

Здравствуйте, CR-LF, Вы писали:

CL>Ну и что, собс-сно, если и так ?

> move(Application.Handle, p^, SizeOf(HWND));

Записываем хендл окна Application, и далее посылаем
ему сообщение, а ожидаем его получить в обработчике формы,
т.е., в другом окне.

>> Во-первых, не все, а только которые Post.
CL>Что значит 'которые Post' ?

Use OnMessage to trap any or all Windows messages posted
to all windows in the application

CL>А главная форма не окно приложения ?

Окно приложения — это совершенно специальное окно,
не имеющая отношения к окнам форм приложения.
Его ты можешь представить как окно, которое показывает
кнопку на таскбаре.

>> CL>SendMessage, PostMessage, PostThreadMessage
>> CL>Какая разница-то в данном случае ?

CL>А вот какая разница в данном случае между PostMessage и PostThreadMessage
CL>ваще непонятно:

В данном случае, это не так и важно, т.е. можно и так PostMessage(hndl,..).
Просто, сообщения посылаемые потоку не будут передаваться окну,
т.е., обработка его закончится в OnMessage.

CL>И есть ли ей разница в каком качестве обрабатывать сообщение ?

Можно представить и такое.

Здравствуйте, Аноним, Вы писали:

LT>>Если нужен полноценный r/w, то нужен еще один (именованный) объект — мьютекс,

А>...и описанная ниже ручная работа

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

А>А мьютексы могут конфликтовать по имени с другими программами, особенно компонентно написанными на Delphi (Mutex1, Mutex2 ии т.д.

В конкретных случаях можно организовать работу и с анонимными объектами,
хоть anonymous pipe. Только, необходим дополнительный способ IPC —
для значения хендла (4 байта).

А>Я боюсь что он может оказаться октрыт не только основной программой.

Если он открыт еще кем-то, значит у кого-то есть его открытый хендл.
Когда будет закрыт последний — система и удалит маппинг.

Здравствуйте, Аноним, Вы писали:

CL>>Ну читал я: SendMessage посылает сообщение и ждет, когда оно будет
CL>>обработано.

А>не послыает оно его, на самом деле, примерно как в VCL метод .Perform

На самом деле посылает. На самом деле у GUI потока есть и такая очередь —
синхронных сообщений. Подробности можно посмотреть у Джефа Рихтера.

Здравствуйте, CR-LF, Вы писали:

CL>Какому бы из них я не посылал сообщение, поток-получатель-то один.

Те, что посланы конкретному окну попадут в его оконную процедуру.
Те, что посланы потоку имеют в параметре msg.Hwnd = 0,
ну и никуда далее не попадут.

>> move(Application.Handle, p^, SizeOf(HWND));
>
> Записываем хендл окна Application, и далее посылаем
> ему сообщение, а ожидаем его получить в обработчике формы,
> т.е., в другом окне.
А-а-а, ну да, ну да

>>> Во-первых, не все, а только которые Post.
> CL>Что значит 'которые Post' ?
>
> Use OnMessage to trap any or all Windows messages posted
> to all windows in the application
А ниже:
Caution: Thousands of messages per second flow though this event. Be careful
when coding the handler, because it can affect the performance of the entire
application.
Хотя, в свете изложенного выше, наверное, все-таки придется писать
Application.OnMessage.
А пока у меня остается

    hndl := FindWindow('TMyForm', 'My form's caption');
    if hndl <> 0 then begin
      SendMessage(hndl,WM_RESTOREFROMTRAY,0,0);
      SetForegroundWindow(hndl);
    end;

И мы вновь возвращаемся к началу нашего увлекательного разговора


> CL>А вот какая разница в данном случае между PostMessage и
> PostThreadMessage
> CL>ваще непонятно:
>
> В данном случае, это не так и важно, т.е. можно и так
> PostMessage(hndl,..).
> Просто, сообщения посылаемые потоку не будут передаваться окну,
> т.е., обработка его закончится в OnMessage.
Ну понял, понял.
Не перестаю я дивиться этому форуму.
Вот если бы в институте так объясняли

> Для совместного доступа, скажем, к физическому файлу ручной работы не
> меньше.
Кстати, а мне идея с физическим файлом нравится.
Главное все просто и понятно