0002518: При запуске второго экзепляра САС с парметрами передавать их уже запущенному

Notes
(0014772) zed (manager) 29-10-2014 10:47	Тут на передний план выходит проблема гарантированного определения/поиска запущенного экземпляра программы и передачи ей управления. Проблема хорошо описана вот тут: Как избежать запуска нескольких экземпляров приложения. Ещё вот тут 0001869:0011022 высказывались некоторые соображения по этому поводу.

(0014774) vdemidov (manager) 29-10-2014 11:29	Отличная статья. Нам нужен вариант, как я понимаю, "Запрет запуска нескольких экземпляров на одном рабочем столе, но разрешается одновременное выполнение нескольких экземпляров приложения на разных рабочих столах" самый простой в реализации. Если еще запускается, то в худшем случае потеряем параметры командной строки.

(0014776) zarius (reporter) 29-10-2014 11:52	>проблема гарантированного определения/поиска запущенного экземпляра программы и передачи ей управления перенесу из 0001869: "Как вариант - назначать при необходимости некий ИД запускаемому SAS. К примеру, --ID="FIRST". Тогда при посылке сообщений мы так же указываем этот ИД. Без указания ИД сообщение уходит первому попавшемуся экземпляру SAS." Плюсом сделать обработку команды "--get-id", которая будет возвращать ID запрашиваемого экземпляра SAS (если он назначен, если нет - то, к примеру, "no-id-1", где 1 - номер экземпляра из заголовка).

(0014777) vdemidov (manager) 29-10-2014 12:01	Та ну его. 99% потребностей обычного юзера будет покрыто передачей первому попавшемуся. Городить огород с --ID="FIRST" и тд я точно не собираюсь.

(0014783) zed (manager) 29-10-2014 12:26	Варианты (a)-(d) из статьи решаются созданием мьютекса с определённым именем, это решение одной проблемы (основной, для той статьи). Другая проблема - поиск хэндла окна. Там тоже приведено несколько вариантов и предлагается использовать разделяемую переменную. И вот тут как раз и появляются вопросы. Нам нужно хранить хэндлы всех запущенных копий, но нет гарантии, что эти хэндлы будут валидны, если к примеру, одна копия упадёт и не сможет удалить себя из списка. Точно так же, остаётся проблема "гонки состояний" когда первая копия уже запущена, но окно ещё не создано и хэндла в списке нету, а уже пытается запуститься вторая копия. Или когда вторая копия взяла хэндл и в тот же момент первая программа решила закрыться и прекратила обработку сообщений. Т.е. ни метод EnumWindows ни использование разделяемой памяти не дают абсолютных гарантий. Какие есть ещё методы?

(0014786) vdemidov (manager) 29-10-2014 12:42 edited on: 29-10-2014 12:53	EnumWindows отличный вариант. В худшем случае потеряется одна командная строка. (С трудом представляю, как пользователь лихорадочно набивает вторую консольную команду что бы успеть до того как закончит стартовать программа запущенная первой командой. Чаще всего это буде уже давно запущенное приложение и клик по ассоциированному файлу).

(0014787) zed (manager) 29-10-2014 12:53	Очень отличный: Один из наиболее распространенных кустарных методов (и, увы, его же я использовал годами) - использование EnumWindows, вызов SendMessage для каждого окна, и анализ кода возврата из SendMessage. Вы посылаете зарегистрированное оконное сообщение (см. мой обзор "Управление Сообщениями"), и, если вы получаете это сообщение, то возвращаете TRUE. Все остальные окна не распознают это сообщение и возвратят FALSE. Этот способ оказывается глубоко ошибочным по ряду причин.

(0014788) vdemidov (manager) 29-10-2014 12:54	Это если без мьютекса его применять.

(0014789) vdemidov (manager) 29-10-2014 12:55	Смотри внимательно код. Автор ничего не имеет против поиска окна после проверки мюткса, только предупреждает, что да можете еще не успеть создаться окно при одновременном старте.

(0014790) zed (manager) 29-10-2014 13:03	Этот способ довольно кастыльный, который "более-менее работает" (c). Там и таймаут для SendMessage нужен и в обработке сообщений нужно возвращать свой код, а не полагаться на винду. Ну и мьютекс нужно держать залоченным.

(0014792) vdemidov (manager) 29-10-2014 13:11	На мой взгляд вполне нормальный. Лучшего все равно нет.

(0020338) zed (manager) 01-06-2022 15:03	Сделал.

Users who viewed this issue
User List	Anonymous (3285x), stepanxxx (1x), vdemidov (13x), ingener (1x), zed (6x), SlavutichRED (1x), karat440 (1x), Crursh-91 (3x), hrucker (3x), netsky (1x), Tolik (2x), DimaDD (1x), zarius (1x), GunSmoker (1x)
Total Views	3320
Last View	21-11-2024 13:24

Issue History
Date Modified	Username	Field	Change
29-10-2014 09:59	vdemidov	New Issue
29-10-2014 09:59	vdemidov	Issue generated from: 0001869
29-10-2014 09:59	vdemidov	Relationship added	related to 0001869
29-10-2014 10:00	vdemidov	Relationship added	child of 0000033
29-10-2014 10:01	vdemidov	Status	new => confirmed
29-10-2014 10:47	zed	Note Added: 0014772
29-10-2014 11:29	vdemidov	Note Added: 0014774
29-10-2014 11:52	zarius	Note Added: 0014776
29-10-2014 12:01	vdemidov	Note Added: 0014777
29-10-2014 12:26	zed	Note Added: 0014783
29-10-2014 12:42	vdemidov	Note Added: 0014786
29-10-2014 12:53	zed	Note Added: 0014787
29-10-2014 12:53	vdemidov	Note Edited: 0014786	View Revisions
29-10-2014 12:54	vdemidov	Note Added: 0014788
29-10-2014 12:55	vdemidov	Note Added: 0014789
29-10-2014 13:03	zed	Note Added: 0014790
29-10-2014 13:11	vdemidov	Note Added: 0014792
21-01-2015 10:39	vdemidov	Target Version	150915 => 151010
04-10-2015 15:30	vdemidov	Target Version	151010 => 151111
06-11-2015 08:20	vdemidov	Target Version	151111 => 191221
18-07-2016 06:46	vdemidov	Relationship added	child of 0003109
23-07-2019 16:56	vdemidov	Target Version	191221 => 211230
30-12-2021 08:58	zed	Target Version	211230 => 26xxxx
01-06-2022 15:03	zed	Note Added: 0020338
01-06-2022 15:03	zed	Status	confirmed => resolved
01-06-2022 15:03	zed	Fixed in Version	=> 24xxxx
01-06-2022 15:03	zed	Resolution	open => fixed
01-06-2022 15:03	zed	Assigned To	=> zed
01-06-2022 15:03	zed	Target Version	26xxxx => 24xxxx
07-07-2022 08:47	zed	Target Version	24xxxx => 220707
07-07-2022 08:48	zed	Fixed in Version	24xxxx => 220707

SASGIS