Посылка сообщений окну другого процесса

[Dimka]

Собственно, начиная с Vista на попытку это сделать говорит LastError = 5 (Access denied.)

Например, SendMessage(hwnd, WM_CLOSE, null, null). Меня интересует сообщение WM_COPYDATA.

Это теперь в принципе запрещено, или же надо как-то права настроить? Если настроить, то как?

[Алексей++]

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

а насчёт доступа - это что-то системное

[zubr]

И WM_CLOSE в 7-ке 100% работает.

[Dimka]

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

И ещё access denied наблюдается, если экземпляр-приёмник запущен с правами администратора, а экземпляр-источник без таких прав.

[zubr]

Dimka, это для того чтобы мог работать только один экземпляр приложения?

[Dimka]

zubr, типа того.

[Алексей++]

проще глобальный именованный мутекс создать

[zubr]

Согласен с Алексей1153++

[zubr]

Ну а если надо закрывать не вновь запускаемый экземпляр, а уже запущенный, то как вариант, можно сделать следующее:
1. При запуске создавать именованный FileMapping объект - если таковой уже есть - значит уже есть запущенный экземпляр.
2. Если есть запущенный экземпляр, то читаем в расшаренной памяти хендл окна данного экземпляра приложения и посылаем ему WM_CLOSE.
3. Если нет запущенного экземпляра, то записываем в расшаренную память хендл окна.

[Dimka]

Да я бы вообще WCF-сервис сделал. Только лень мне. Особливо лень MapFile в C# делать под .NET 2.0 на WinAPI, поскольку в библиотеке он появился только в 4.0. Он у меня был написан на C++.NET, но в C# это copy-paste не перетянуть, а лишние dll не приветствуются.

Мьютекса недостаточно, ещё нужна передача параметров командной строки между процессами.

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

Не будет устраивать по каким-то причинам - переделаю на мап-файлы. С WCF-сервисом дополнительное неудобство - многопоточность. Обработка же сообщений последовательна в одном потоке.

[v2]

A NamedPipe не подойдет? Первый экземпляр становится "сервером", а остальные к нему подключатся.

[Dimka]

v2, NamedPipe - это транспорт, а инфраструктура в WCF.

[v2]

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

кстати, не понял про
> стабильная среда рабочей станции при оборудовании

[Dimka]

v2, WM_COPYDATA не совсем то. Любой транспорт - это поток. Соответственно, в программе нужно держать нечто, ожидающее поступления в поток порции данных. Либо это будет отдельная нить, "висящая" на ожидании, либо периодический опрос: по таймеру или в главном цикле приложения. WM_COPYDATA - это не поток, это отдельное сообщение, событие для окна: послал, поймал и забыл. Это ближе к сигналам, нежели потокам.

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

Круто. А зачем мне эти "очереди клиентов", которых в реальности нет? Ко всему прочему WM_COPYDATA и так упорядочивается и синхронизируется за счёт последовательной обработки сообщений ловящим процессом.

стабильная среда рабочей станции при оборудовании

Это значит, что программа не для неопределённого круга пользователей с "зоопарком" не пойми чего.
Это значит, что компьютер стоит при оборудовании, и на этом компьютере только то, что нужно для работы с оборудованием, и ничего более.
Это значит, что вероятность совпадения названий окон разных приложений и доставка WM_COPYDATA не тому адресату равна нулю.
Это значит, что ОС не серверная, и количество сессий пользователей строго не больше 1, поэтому вероятность одновременной работы экземпляров приложения в разных сессиях равна нулю.
Это значит, что одновременный запуск нескольких экземпляров, или работа пользователя с приложением, в то время, как ему приходит WM_COPYDATA невозможен чисто физически: либо пользователь работает с приложением, либо делает нечто другое, приводящее к запуску приложения.
Это значит, что вероятность нарваться на Access denied, о чём и была тема, либо 0, либо 1, поскольку порядок эксплуатации приложения полностью определённый.

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

[v2]

Круто!
> Любой транспорт - это поток.
Любое сообщение - частный случай и/или составляющая потока.
А дополнительная нить с минимальным функционалом - вроде, не так уж и страшно.

> А зачем мне эти "очереди клиентов", которых в реальности нет?
а как же
>>> обмен между экземплярами одного и того же приложения

> Это значит, что ОС не серверная, и количество сессий пользователей строго не больше 1
Это так уже есть или иллюзию этого создаст использование FindWindow + WM_COPYDATA ?

Если
>>> Мьютекса недостаточно, ещё нужна передача параметров командной строки между процессами.
то сущность, реализующую этот функционал, скорее всего,  можно будет обозвать WCF'ом.

...

P.S.
Сообщение состоит из риторических вопросов и мыслей вслух.

[Dimka]

Любое сообщение - частный случай и/или составляющая потока.

Ну да, это поток сообщений процессу, вся инфраструктура для которого уже есть, и всё приложение основано на главном цикле обработки. Я просто этим пользуюсь.

А дополнительная нить с минимальным функционалом - вроде, не так уж и страшно.

Никто и не говорил, что это страшно.

> А зачем мне эти "очереди клиентов", которых в реальности нет?
а как же
>>> обмен между экземплярами одного и того же приложения

Не вижу, где посылка единственного сообщения между парой процессов превращается в "очередь клиентов".

> Это значит, что ОС не серверная, и количество сессий пользователей строго не больше 1
Это так уже есть или иллюзию этого создаст использование FindWindow + WM_COPYDATA ?

Коли бы ты знал условия эксплуатации, ты бы не фантазировал попусту.

Если
>>> Мьютекса недостаточно, ещё нужна передача параметров командной строки между процессами.
то сущность, реализующую этот функционал, скорее всего,  можно будет обозвать WCF'ом.

WCF.NET - это не сущность, а framework для RPC.

[v2]

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

Я и не знаю - поэтому и фантазирую и вопрошаю:

 Если архитектура такова, что экземпляр №2 передает данные экземпляру №1, то возможна и ситуация когда в это же время работает экземпляр №3, который тоже должен передать данные экземпляру №1 - вот и очередь для подключений к "моноконнектному" NamedPipe. Для сообщений же возможно, что №3 "найдет" первым №2, и передаст ему данные вместо №1, что не хорошо.

 Если есть необходимость работы №1 с админ атрибутами, а запуск №2 .. №х происходит без оных, то с помощью NamedPipe можно разрешить и это. Кстати, в связи с этим, условие, что ОС не серверная, и количество сессий пользователей строго не больше 1, можно поставить под сомнение.

[Dimka]

Если архитектура такова, что экземпляр №2 передает данные экземпляру №1, то возможна и ситуация когда в это же время работает экземпляр №3, который тоже должен передать данные экземпляру №1 - вот и очередь для подключений к "моноконнектному" NamedPipe. Для сообщений же возможно, что №3 "найдет" первым №2, и передаст ему данные вместо №1, что не хорошо.

Нет. Архитектура не такова. Во-первых, экземпляр 3 почти невозможен - пользователь не успеет его запустить после 2. Во-вторых, смена порядка не имеет значения.

Если есть необходимость работы №1 с админ атрибутами, а запуск №2 .. №х происходит без оных, то с помощью NamedPipe можно разрешить и это. Кстати, в связи с этим, условие, что ОС не серверная, и количество сессий пользователей строго не больше 1, можно поставить под сомнение.

Можно не значит нужно. А сомневаться тебе, конечно, никто не запрещает. Ты же лучше знаешь условия эксплуатации