View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002518 | SAS.Планета | Хотелка / Feature request | public | 29-10-2014 09:59 | 07-07-2022 08:48 |
| Reporter | vdemidov | Assigned To | zed | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | XP | OS Version | SP3 |
| Product Version | 131111 | ||||
| Target Version | 220707 | Fixed in Version | 220707 | ||
| Summary | 0002518: При запуске второго экзепляра САС с парметрами передавать их уже запущенному | ||||
| Description | При запуске второго экземпляра САС с параметрами командной строки, но без параметра --new-instance, передавать их уже запущенному экземпляру при помощи WM_COPYDATA и сразу закрывать только-что запущенный экземпляр. Если запущено уже больше одного экзепляра, то передавать первому попавшемуся | ||||
| Tags | No tags attached. | ||||
|
|
Тут на передний план выходит проблема гарантированного определения/поиска запущенного экземпляра программы и передачи ей управления. Проблема хорошо описана вот тут: Как избежать запуска нескольких экземпляров приложения. Ещё вот тут 0001869:0011022 высказывались некоторые соображения по этому поводу. |
|
|
Отличная статья. Нам нужен вариант, как я понимаю, "Запрет запуска нескольких экземпляров на одном рабочем столе, но разрешается одновременное выполнение нескольких экземпляров приложения на разных рабочих столах" самый простой в реализации. Если еще запускается, то в худшем случае потеряем параметры командной строки. |
|
|
>проблема гарантированного определения/поиска запущенного экземпляра программы и передачи ей управления перенесу из 0001869: "Как вариант - назначать при необходимости некий ИД запускаемому SAS. К примеру, --ID="FIRST". Тогда при посылке сообщений мы так же указываем этот ИД. Без указания ИД сообщение уходит первому попавшемуся экземпляру SAS." Плюсом сделать обработку команды "--get-id", которая будет возвращать ID запрашиваемого экземпляра SAS (если он назначен, если нет - то, к примеру, "no-id-1", где 1 - номер экземпляра из заголовка). |
|
|
Та ну его. 99% потребностей обычного юзера будет покрыто передачей первому попавшемуся. Городить огород с --ID="FIRST" и тд я точно не собираюсь. |
|
|
Варианты (a)-(d) из статьи решаются созданием мьютекса с определённым именем, это решение одной проблемы (основной, для той статьи). Другая проблема - поиск хэндла окна. Там тоже приведено несколько вариантов и предлагается использовать разделяемую переменную. И вот тут как раз и появляются вопросы. Нам нужно хранить хэндлы всех запущенных копий, но нет гарантии, что эти хэндлы будут валидны, если к примеру, одна копия упадёт и не сможет удалить себя из списка. Точно так же, остаётся проблема "гонки состояний" когда первая копия уже запущена, но окно ещё не создано и хэндла в списке нету, а уже пытается запуститься вторая копия. Или когда вторая копия взяла хэндл и в тот же момент первая программа решила закрыться и прекратила обработку сообщений. Т.е. ни метод EnumWindows ни использование разделяемой памяти не дают абсолютных гарантий. Какие есть ещё методы? |
|
|
EnumWindows отличный вариант. В худшем случае потеряется одна командная строка. (С трудом представляю, как пользователь лихорадочно набивает вторую консольную команду что бы успеть до того как закончит стартовать программа запущенная первой командой. Чаще всего это буде уже давно запущенное приложение и клик по ассоциированному файлу). |
|
|
Очень отличный: Один из наиболее распространенных кустарных методов (и, увы, его же я использовал годами) - использование EnumWindows, вызов SendMessage для каждого окна, и анализ кода возврата из SendMessage. Вы посылаете зарегистрированное оконное сообщение (см. мой обзор "Управление Сообщениями"), и, если вы получаете это сообщение, то возвращаете TRUE. Все остальные окна не распознают это сообщение и возвратят FALSE. Этот способ оказывается глубоко ошибочным по ряду причин. |
|
|
Это если без мьютекса его применять. |
|
|
Смотри внимательно код. Автор ничего не имеет против поиска окна после проверки мюткса, только предупреждает, что да можете еще не успеть создаться окно при одновременном старте. |
|
|
Этот способ довольно кастыльный, который "более-менее работает" (c). Там и таймаут для SendMessage нужен и в обработке сообщений нужно возвращать свой код, а не полагаться на винду. Ну и мьютекс нужно держать залоченным. |
|
|
На мой взгляд вполне нормальный. Лучшего все равно нет. |
|
|
Сделал. |
| 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 | |
| 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 => 42xxxx |
| 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 | => 41xxxx |
| 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 | 42xxxx => 41xxxx |
| 07-07-2022 08:47 | zed | Target Version | 41xxxx => 220707 |
| 07-07-2022 08:48 | zed | Fixed in Version | 41xxxx => 220707 |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |