Ограничение числа экземпляров

← →
Piter © (2006-03-25 02:16) [40]

Defunct © (25.03.06 1:46) [39]
Напоминает отрывок из Шрека:
- Ириски! Все любят ириски! Шрек, ты любишь ириски?

а ты всегда это пишешь, когда предлагают решение БОЛЕЕ оптимальное, чем твое?

Defunct © (25.03.06 1:46) [39]
Хотя к сожалению оно не сработает, одна копия таки останется

почему не сработает? Расскажи. Ты видимо ковырял исходники Windows.

Defunct © (25.03.06 1:46) [39]
Например, чтобы передать параметры или выполнить кое-какие действия.

думаю, создание формы для этого вовсе не обязательно. Причем, такое создание, что в OnCreate вызывается Halt...

← →
Piter © (2006-03-25 02:18) [41]

Defunct © (25.03.06 1:46) [39]
Т.к. ни один дибил не будет специально кликать по 30 раз на твоей программе

я тебе уже писал, что мне удавалось открыть 2 окошка установления одного Dial-up соединения. Правда, в этом время компьютер дикто тормозил и жутко свопил, но какая разница. И я не тыкал 30 раз.

← →
Defunct © (2006-03-26 03:40) [42]

Piter © (25.03.06 02:16) [40]
> а ты всегда это пишешь, когда предлагают решение БОЛЕЕ оптимальное, чем твое?

Я не настаиваю на своем решении и тем более не говорю, что оно самое оптимальное и все должны делать именно так. Просто оно (решение) есть, и работает надежно. И нафига, конкретно мне мьютексы?
"Людоеды любят лук."

> думаю, создание формы для этого вовсе не обязательно. Причем, такое создание, что в OnCreate вызывается Halt...
imho - это уже из разряда экономии спичек.

> я тебе уже писал, что мне удавалось открыть 2 окошка установления одного Dial-up соединения.
Ну и что? Может окошко диалап соединения использует мьютексы? Или у тебя есть уверенность, что оно использует сообщения? Что-то мысль твою не уловил.

← →
Piter © (2006-03-26 17:23) [43]

Defunct © (26.03.06 3:40) [42]
И нафига, конкретно мне мьютексы?

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

Я придерживаюсь принципа, что если можно сделать лучше - то надо сделать лучше, несмотря на то, что другое решение будет работать в 99% случаев. Но если теми же усилиями ты можешь сделать так, чтобы работало в 100% случаев - то надо сделать так.

Defunct © (26.03.06 3:40) [42]
Может окошко диалап соединения использует мьютексы?

если бы оно использовало мьютексы - такой ситуации в принципе не могло бы возникнуть.

← →
MegaVolt © (2006-03-27 17:26) [44]

99% в одном месте 99% в другом в результате уже вероятность сбоя 2%
Если таких мест 100 то прога будет глючить стабильно. Вот чтобы этого не было и стараются хоть там где это точно возможно сделать 100% а не 99%

← →
Defunct © (2006-03-28 02:35) [45]

Piter © (26.03.06 17:23) [43]
> если бы оно использовало мьютексы - такой ситуации в принципе не могло бы возникнуть.

Тогда откуда у тебя вдруг такая уверенность, что там именно сообщения и используются именно так, как привел я в [34].
Криво можно написать что угодно.

> Мы говорим про оптимальные и правильные решения.
По поводу первого критерия - "оптимальность" - понятие растяжимое.
По поводу второго - если ты хочешь сказать, что мое решение неправильное - тогда найди ошибку.

> Я придерживаюсь принципа, что если можно сделать лучше - то надо сделать лучше, несмотря на то, что другое решение будет работать в 99% случаев. Но если теми же усилиями ты можешь сделать так, чтобы работало в 100% случаев - то надо сделать так.

1. Что-то я не вижу варианта с мьютексами.
2. Вариант с сообщениями лично меня ни разу не подвел, поэтому могу сказать, что он на 100% надежен.

>>Defunct © (26.03.06 3:40) [42]
>>Может окошко диалап соединения использует мьютексы?
>если бы оно использовало мьютексы - такой ситуации в принципе не могло бы возникнуть.
Да что ты такое говоришь? Мьютекс лишь средство, а более важный вопрос это то - как это средство используется программистом. Программист может все испаганить сам имея в арсенале очень мощные средства..
Я могу с полной уверенностью сказать, что задачу автора можно надежно решить любыми средствами обспечивающими общий доступ (шару) в т.ч. даже с помощью общего файла, общего сокета, общего ключа системного реестра и т.п., главное чтобы используемый ресурс был общим.

← →
Leonid Troyanovsky © (2006-03-28 14:18) [46]

> Defunct © (28.03.06 02:35) [45]

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

Одну ошибку видно сразу: не foreground приложению не положено
делать себя foreground.

Кроме того, мне очень не нравятся бродкасты, хотя, конечно,
это не ошибка.

> 1. Что-то я не вижу варианта с мьютексами.

Я бы лучше увидел вариант с проекцией файла :)
Однако, сразу оговорюсь: должен быть обоснован выбор имени,
бо зашивать в код, скажем, GUID мне представляется корявым.

> 2. Вариант с сообщениями лично меня ни разу не подвел, поэтому
> могу сказать, что он на 100% надежен.

Чтобы подлить масла в огонь, предложу свой давнишний вариант

http://groups.google.com/group/borland.public.delphi.winapi/msg/b2ebfc63eb002ebe

Хотя, конечно, и он не свободен от недостатков (кто заметит - каких?),
но, со своей задачей он справляется вполне успешно.

--
Regards, LVT.

← →
Piter © (2006-03-28 17:23) [47]

Defunct © (28.03.06 2:35) [45]
Тогда откуда у тебя вдруг такая уверенность, что там именно сообщения и используются именно так, как привел я в [34].

я, собственно, не говорил, что там используется твой вариант

Defunct © (28.03.06 2:35) [45]
По поводу второго - если ты хочешь сказать, что мое решение неправильное - тогда найди ошибку.

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

Defunct © (28.03.06 2:35) [45]
Что-то я не вижу варианта с мьютексами

ты его легко можешь сам реализовать. И он прописан везде, в интернете куча примеров, в книжках многих написан

Defunct © (28.03.06 2:35) [45]
Вариант с сообщениями лично меня ни разу не подвел, поэтому могу сказать, что он на 100% надежен

Ну тут даже и без комментариев.

Ты вполне можешь следовать логике "Если я не вижу ошибок - значит, их нет" - пожалуйста. Я пытаюсь по другому.

← →
Leonid Troyanovsky © (2006-03-28 19:14) [48]

> Piter © (21.03.06 20:28) [17]

> * у тебя элементарно нету ОДНОЙ функции, которая может проверить
> наличие окна и создать новое

У меня есть. Только это не совсем функция, а, скажем, подход.
Но, сути ж оно не меняет?

--
Regards, LVT.

← →
Defunct © (2006-03-29 01:44) [49]

Piter © (28.03.06 17:23) [47]
Бессмысленное переливание из пустого в порожнее.
(это не к тебе лично относится, а к тому во что превратилась ветка).

Leonid Troyanovsky © (28.03.06 14:18) [46]
> Одну ошибку видно сразу: не foreground приложению не положено
делать себя foreground.
Здесь я не соглашусь.. Т.к. по сути foreground приложение передает фокус своей более старой копии самостоятельно и добровольно.

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

← →
Leonid Troyanovsky © (2006-03-29 08:37) [50]

> Defunct © (29.03.06 01:44) [49]

> Здесь я не соглашусь.. Т.к. по сути foreground приложение
> передает фокус своей более старой копии самостоятельно и
> добровольно.

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

Хотя, более точно restrictions описаны в remarks to LockSetForegroundWindow

--
Regards, LVT.

← →
Fay © (2006-03-29 20:12) [51]

2 Leonid Troyanovsky © (28.03.06 14:18) [46]
> GUID мне представляется корявым
Корявее, чем FindWindow? Ню-ню...

← →
Defunct © (2006-03-30 03:56) [52]

Leonid Troyanovsky © (29.03.06 08:37) [50]

Ссылка к сожалению у меня не открылась.

Если там речь идет о рекомендациях не использовать SetForegroundWindow и
MS считает, что запустив приложение, которое просто молча сгинет из-за присутствия более старой копии и не передаст фокус старой копии - допустимо, то пусть они со своими ограничениями катятся куда подальше. Более того на это у меня есть мнение - идиотов хватает и среди тех кто пишет правила. До инфаркта пользователя нехорошо доводить, а это поверьте возможно, когда пром. программа "откажется" запускаться без причины.

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

← →
Leonid Troyanovsky © (2006-03-30 09:06) [53]

> Fay © (29.03.06 20:12) [51]

> > GUID мне представляется корявым

> Корявее, чем FindWindow? Ню-ню...

Зашить в код GUID - конечно, более корявое решение.
Лично я предпочту EnumWindows (хотя, и не совсем FindWindow).
Для гуевых дельфийских приложений этого вполне хватает.
Неатомарность сочетания if EnumWindows() then .. меня
вовсе не расстраивает, бо в самом плохом случае (скажем, на
двухпроцессорной машине при "удачном" стечении обстоятельств)
запустятся два приложения, но это никак не должно отразиться на
их работоспособности.

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

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

Поэтому, ничего зашивать в код и не следует.

Ну, а для полноты же картины я бы упомянул еще один подход:

http://groups.google.com/group/fido7.ru.delphi.chainik/msg/278f89887ab26b31

--
Regards, LVT.

← →
Leonid Troyanovsky © (2006-03-30 09:08) [54]

> Defunct © (30.03.06 03:56) [52]

> Ссылка к сожалению у меня не открылась.

Сочуствую.
Вообще-то, http://msdn.microsoft.com весьма полезный ресурс,
бо содержит наиболее актуальную информацию.
Так что, стоит пнуть своих админов.

--
Regards, LVT.

← →
Рафик © (2006-03-30 10:14) [55]

А если я программу запущу от разных пользователей?

← →
Leonid Troyanovsky © (2006-03-30 11:33) [56]

> Рафик © (30.03.06 10:14) [55]

> А если я программу запущу от разных пользователей?

Разные пользователи работают в разных сессиях.

--
Regards, LVT.

← →
Alexander Panov © (2006-03-30 12:12) [57]

Что вы спорите?
Предлагаю корректно реализовать эту задачу с такими начальными условиями:

1. Возможен запуск только одной копии программы.
2. Если копия программы запущена, переместить запущенный экземпляр на передний план.
3. ОС - Windows 2000 и выше.
А дальше уже можно критиковать.

PS.
Приложение оконное.

← →
Leonid Troyanovsky © (2006-03-30 14:37) [58]

> Alexander Panov © (30.03.06 12:12) [57]

> А дальше уже можно критиковать.

Я уже привел, по-крайней мере, два варианта.
Если хочешь, вот и третий:

=== Вариант с Мьютексом ===
В файле проекта (.dpr) прямо можешь написать нечто вроде:
uses windows,... var H: THandle; begin H := CreateMutex(nil, True, "уникальное_имя_для_твоей_проги"); if GetLastError = ERROR_ALREADY_EXISTS then begin H := FindWindow(nil, "название заголовка окна программы"); SetForegroundWindow(H); Exit; end; Application.Initialize; Application.Title := "название заголовка окна программы"; Application.CreateForm(TAppData, AppData); Application.CreateForm(TMain, Main); Application.Run; CloseHandle(H); end;

Прочко Денис Владимирович.
sysadmin@)farmeko.khv.ru

Для критики все готово.

--
Regards, LVT.

← →
Рафик © (2006-03-30 14:56) [59]

> Разные пользователи работают в разных сессиях.

Винда позволяет запускать в одной сессии из под разных пользователей

← →
Leonid Troyanovsky © (2006-03-30 15:14) [60]

> Рафик © (30.03.06 14:56) [59]

> Винда позволяет запускать в одной сессии из под разных пользователей

И, что?

Окна, расположенные на однов десктопе, доступны для перечисления
EnumWindows, EnumThreadWindows & etc.
Объекты ядра могут иметь локальные имена (в пределах сессии),
а также и глобальные, с префиксом Global\, на все.

--
Regards, LVT.

← →
Alexander Panov © (2006-03-30 16:31) [61]

> Leonid Troyanovsky © (30.03.06 14:37) [58

В этом варианте при не поднимется на передний план.
Конечно, перед SetForegroundWindow можно выполнить ShowWindow(H,SW_SHOW), но вот такой вариант исключает находждение окна:

procedure TForm1.FormCreate(Sender: TObject); begin Application.Title := "test"; end;

← →
Alexander Panov © (2006-03-30 16:32) [62]

>Leonid Troyanovsky © (30.03.06 15:14) [60]

А необходимость в динамическом изменении хинта к приложению возникает довольно часто для отображения нужной информации во всплывающем хинте приложения на панели задач.

← →
Leonid Troyanovsky © (2006-03-30 18:59) [63]

> Alexander Panov © (30.03.06 16:31) [61]

> В этом варианте при не поднимется на передний план.
> Конечно, перед SetForegroundWindow можно выполнить ShowWindow(H,
> SW_SHOW),

Если речь про [58], то там не совсем точно, т.е. нужно SFW для
окна приложения.
procedure ActivatePrevInstance(wnd: HWND); var h : HWND; begin h := GetWindowLong(wnd, GWL_HWNDPARENT); if IsIconic(h) then ShowWindow(h, SW_RESTORE); SetForegroundWindow(h); end;

> такой вариант исключает находждение окна:

Есть еще и класс. Кстати, ранее я предлагал, как это обходится -
использованием mmf vs mutex, в который и писать нужный хендл.

--
Regards, LVT.

← →
Defunct © (2006-03-30 19:28) [64]

Leonid Troyanovsky © (30.03.06 09:08) [54]

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

MSDN полный у меня установлен локально, и по инету мне шариться не приходится в поиске описания той или иной функции. В MSDN (April 2003) который у меня установлен нет никаких restrictions на использование SetForegroundWindow.

> Leonid Troyanovsky © (30.03.06 18:59) [63]
> Есть еще и класс. Кстати, ранее я предлагал, как это обходится -
> использованием mmf vs mutex, в который и писать нужный хендл.

А какой смысл в этом? Если только ваши предрассудки, то проще продолжать использовать HWND_BROADCAST.

← →
Alexander Panov © (2006-03-30 21:54) [65]

> Defunct © (30.03.06 19:28) [64]
</I
> проще продолжать использовать HWND_BROADCAST.

>

Ну так приведи рабочий пример;)

← →
Alexander Panov © (2006-03-30 22:18) [66]

> Defunct © (23.03.06 12:57) [27]
>
> Я для этой цели использую RegisterWindowMessage, при старте
> посылаю сообщение всем окнам, если в системе уже запущена
> копия программы, то словив это сообщение она выдвигает себя
> на передний план, и отсылает только что запущенной программе
> сообщение, чтобы та себя закрыла.

Вот критика этого метода:

1. Какой смысл в RegisterWindowMessage, если получающая программа не знает, какое сообщение обрабатывать?
2. Пример выдвижения программы самой себя тоже неплохо бы увидеть;)
3. Для того, чтобы только что запущенная вторая копия могла обработать сообщение, должно хотя бы быть создано хотя бы одно окно в приложении. Таковым является для VCL MainForm. Но в MainForm.OnCreate Может быть проделана масса предварительной работы до того, как окно получит и обработает сообщение, чего никак нельзя допускать.

← →
Defunct © (2006-03-31 01:42) [67]

> Alexander Panov [65] & [66]

[34]...

← →
Alexander Panov © (2006-03-31 02:05) [68]

> Defunct © (31.03.06 01:42) [67]

По поводу кода в [34]:

Не может быть так, что другое приложение ответит на Broadcast?
Что если этим методом пользуются сразу 2 разных приложения?

хе-хе.. ну и раздули жи ветку )
скажу и я своё imho )

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

Насчёт способа определения существования второй копии. Тут ессено единственно правильного варианта нету, иначе бы столько разговоров тоже не было. Всё зависит от типа приложения.
Если данное приложение имеет документо-ориентированную структуру (типа ворда/экселя/винэмпа), то следует применять подход, при котором нам нужно каким то образом сообщить другому приложению о запуске второй копии.
Если приложение не документо-ориентированное, то следует использовать простой именованый объект ядра, но при этом, если вторая копия существует обязательно сообщить об этом юзеру (например через мессадж бокс). Иначе если первая копия повисла (и при этом не видно её окон), а вторая просто не будет запускаться - это приведет юзера в шок и панику :-)

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

> Eraser © (31.03.06 02:11) [69]
>
> хе-хе.. ну и раздули жи ветку )
> скажу и я своё imho )

А стоило ли влезать? Заклюют! Имхо.
И так-то была напряжёнка. Да ещё Саша Панов проснулся. :-) Извини Саша, но иного термина у меня не нашлось. :-(

Alexander Panov © (31.03.06 02:05) [68]

Ничего страшного не произойдет.. Windows все равно один broadcast разошлет раньше другого, а дальше там сплошной блок (с помощью SendMessage). Одно приложение тихо удалится, и на второй броадкаст просто некому будет "отвечать".

> Что если этим методом пользуются сразу 2 разных приложения?

Если речь о разных типах приложений.. Дык тогда разные сообщения пусть регистрируют.
RegisterWindowMessage("Тип программ 1")
RegisterWindowMessage("Тип программ 2")

Alexander Panov © (31.03.06 02:05) [68]

Ваши вроде бы простые вопросы совсем сбили меня с толку..[71] Можете не читать, он был написан, когда я был на своей волне и подумал, что в вопросах тот же контекст, который закладывал Piter(C) выше...

> Не может быть так, что другое приложение ответит на Broadcast?

Нет не может, т.к. зарегистрированное сообщение задается уникальной строкой также как и mutex. Естественно, если Вы зарегистрируете сообщение с именем, которое уже кем-то используется, то тогда есть вероятность что ответит какое-то другое приложение. При этом если рассматривать [34], то это приложение точно не выполнит требуемую цепочку действий, необходимую для закрытия нашего приложения. Т.е. оно не пошлет сообщение WM_DONTINITIALIZE с Handle окна в WParam.

> Что если этим методом пользуются сразу 2 разных приложения?

Ничего, одно приложение работает с одним сообщением, другое - с другим. Друг-другу они мешать не будут.

> Defunct © (30.03.06 19:28) [64]

> Вообще-то чем выпендриваться с сочуствиями, лучше бы ответить

Что мне лучше, я уж сам решу.
И попрошу следить за речью.

> MSDN (April 2003) который у меня установлен нет никаких
> restrictions на использование SetForegroundWindow.

Они есть там, IMHO, начиная с 99 года. Просто, в этой статье
описаны коряво: мол, в 9x/Me, а на самом деле - и в NT5+.
Поэтому, и говорил я, где надо читать более точный текст.

> > использованием mmf vs mutex, в который и писать нужный
> хендл.

> А какой смысл в этом? Если только ваши предрассудки, то

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

--
Regards, LVT.

> Eraser © (31.03.06 02:11) [69]

> Насчёт целесообразности запрета запуска второй копии. Есть
> ситуации когда это необходимо, например любой сервер, который
> слушает определённый порт.

Если необходимо, откроет его эксклюзивно - более ничего
и не требуется (в смысле ограничений). См. ранее по топику.

> разговоров тоже не было. Всё зависит от типа приложения.

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

> Если данное приложение имеет документо-ориентированную структуру
> (типа ворда/экселя/винэмпа), то следует применять подход,
> при котором нам нужно каким то образом сообщить другому
> приложению о запуске второй копии.

Я недавно приводил ссылку на такое решение.

> юзеру (например через мессадж бокс). Иначе если первая копия
> повисла (и при этом не видно её окон), а вторая просто не
> будет запускаться - это приведет юзера в шок и панику :-

Если повисла, то, конечно, сообщить об этом юзеру,
запускать или запускать вторую копию - решать ему.

> замечу, что с окном первого экземпляра ничего не происходит,
> т.е. его не пытаются переместить на первый план.

И почему же его не переместить? Может не умеют? :)

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

--
Regards, LVT.

>> Вообще-то чем выпендриваться с сочуствиями, лучше бы ответить
> Что мне лучше, я уж сам решу.
> И попрошу следить за речью.

И я сам решу каким тоном мне и с кем разговаривать.
Пост [54] заслуживает еще более грубого ответа.
Я люблю прямоту, а не общение с помощью намеков, которое только усложняет фильтрацию смысла из текста.

> Они есть там, IMHO, начиная с 99 года. Просто, в этой статье
> описаны коряво: мол, в 9x/Me, а на самом деле - и в NT5+.
> Поэтому, и говорил я, где надо читать более точный текст.

Кто они?
Если вы об этом:

This method allows SetForegroundWindow on Windows 98/Windows Me and Windows 2000/Windows XP to behave the same as Windows 95 and Windows NT 4.0, respectively, for all applications. The setup application should warn the user that this is being done so that the user isn"t surprised by the changed behavior. On Windows Windows 2000 and Windows XP, the call fails unless the calling thread can change the foreground window, so this must be called from a setup or patch application. For more information, see Foreground and Background Windows.

A process that can set the foreground window can enable another process to set the foreground window by calling the AllowSetForegroundWindow function. The process specified by dwProcessId loses the ability to set the foreground window the next time the user generates input, unless the input is directed at that process, or the next time a process calls AllowSetForegroundWindow, unless that process is specified.

The foreground process can disable calls to SetForegroundWindow by calling the LockSetForegroundWindow function.

тогда либо вы, либо я неправильно понимаем написанное в MSDN. Конкретно мое приложение не использует LockSetForegroudWindow, соответственно никаких проблем на которые вы так упорно уже 4-й раз намекаете, но прямо ничего не говорите, быть не может.

И все-таки...

Думаю, что существуют 3 универсальных решения. Одно для безоконных приложений(с этим как раз проблем нет), второе для оконных, третье для консольных.

Задача для безоконного приложения тривиальна. Задача для оконного не так тривиальна, но решаема вполне.

А вот для консольного(эта мысль возникла только сейчас) - не знаю. Даже не занимался вопросом. Хотя стоит подумать.

Alexander Panov © (31.03.06 09:31) [77]

должно быть просто:
или консольное приложение отнести к "безоконным",
или создав невидимое окошко - перевести в разряд "оконных"
;>

> Defunct © (31.03.06 09:10) [76]

Ну я вообще не просто так написал в [66] (2. Пример выдвижения программы самой себя тоже неплохо бы увидеть;)). Выдвижение окна самого себя на передний план не такая тривиальная задача-). Просто покритиковать хотелось;)

В MSDN написано про not foreground winndow, но там есть одна мальнькая деталь. Я ее, например, не уловил сразу, из-за чего было сломано немало копий в споре.

> Defunct © (31.03.06 03:34) [71]
>
> Alexander Panov © (31.03.06 02:05) [68]
>
> Ничего страшного не произойдет.. Windows все равно один
> broadcast разошлет раньше другого, а дальше там сплошной
> блок (с помощью SendMessage). Одно приложение тихо удалится,
> и на второй броадкаст просто некому будет "отвечать".

Если это твое приложение. А если чужое, но использует тот же номер сообщения?

Ситуация маловероятна, но возможна. А то, что возможно, бывает происходит чаще, чем хотелось бы.

> Defunct © (31.03.06 09:36) [78]
>
> Alexander Panov © (31.03.06 09:31) [77]
>
> должно быть просто:
> или консольное приложение отнести к "безоконным",
> или создав невидимое окошко - перевести в разряд "оконных"
> ;>

Проблема во второй части задачи: вывести на передний план.

Я пока не пытался работать с консольными приложениями. Если бы они ничем не отличались от оконных, тогда никаких проблем не было бы.-)

Ограничение числа экземпляров Найти похожие ветки