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

К>Усложнением не подходит.
К>Тебе нужно из процесса Б просечь, что запущен процесс А и у него есть окно (сплеш-скрин), и успеть прицепиться к этому окну.

Что же здесь сложного (тем более, что процессы А и Б сам ТС и запускает) ?

К>А затем из процесса А — не убиваться, пока процесс Б не отцепил свои дочерние окна (месседж-боксы).

А вот тут есть занятный момент.

MSDN/Window Features/Owned Windows:
(1)
> An owned window is always above its owner in the z-order.
(2)
> The system automatically destroys an owned window when its owner is destroyed.
(3)
> An owned window is hidden when its owner is minimized.

Так вот: "не убиваться из процесса А, пока процесс Б не отцепил свои дочерние окна" —
— при назначении на роль owner-а окна из другого процесса —
— незачем, ибо в этом случае фича №2 отменяется!
Ага, строго говоря — ну не совсем канонический у нас owner в этом случае,
однако фича №1 (как и №3) остается в силе, а именно она-то нам и нужна

---
Что касается сплэша, то по-моему — тут мы попросту оказались в перпендикуляре:
kero исходил из того, что сплэш как таковой есть условие задачи и точка, а Кодт и Carc стояли на том, что сплэш плох сам по себе, — не так ?

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

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

W>Есть прога, она показывает по центу экрана сплеш-скрин при старте (как окно, со стилем WS_POPUP). При запуске прога также запускает еще один процесс.

W>Если в порожденном процессе чего-то нехватает, то он о этом сообщает юзеру вызывая
W>

W>    MessageBox(NULL,"Device not ready. Please attach it and click OK","Not ready!", MB_OK |
W>                      MB_ICONINFORMATION|MB_TOPMOST);
W>

W>(и пока юзер не ткнет ОК, работу не продолжает).

W>Проблема в том, что в иногда в некоторых виндах (кажется в висте и семерке, но иногда и в XP бьвает) сплеш скрин перекрывает то сообщение об ошибке, юзер его не замечает (несмотря на то, что в таскбаре новое окно появляется), и юзер жалуется что прога зависла.

W>Вопрос — как сделать чтобы онкно, созданное MessageBox оказалось ПОВЕРХ сплеш скрина? Если c MessageBox это невозможно, тогда как сообщить юзеру о проблеме чтобы гарантировано сообщение оказалось поверх сплеш скрина?

W>Спасибо заранее за ответы!

Здравствуйте.
Вот моё предложение:
1. Создаём именованное событие для идентификации ошибки инициализации.
2. В процессе, который изначально выводил MsgBox, устанавливаем его при возникновении ошибки и закрываемся.
3. В процессе со сплешем ожитаем это событие ( по таймеру или в отдельном утилитном потоке ) и при срабатывании выводим MsgBox с установленным в сплеш парентом.

[поскипано]
K>---
K>Что касается сплэша, то по-моему — тут мы попросту оказались в перпендикуляре:
K>kero исходил из того, что сплэш как таковой есть условие задачи и точка, а Кодт и Carc стояли на том, что сплэш плох сам по себе, — не так ?
Хм, нет! Не так.
TC куда-то запропастился... Тут нужно сразу определиться если возможность менять код сплеша? Если есть — надо менять, ну *авно ситуация по юзабилити, по сути своей *авно. Нужно переделывать. Вот выше писал про проблему с TopMost сплеша у Бата

Автор: Carc
Дата: 09.09.09

. Ну дык так оно и есть — именно Батова работа. Ох и достал он перекрывать вопрошающий Аутлук
Какая разница-то!?! Ну с соседним процессом TC, хитрости с MessageBox работать будут, а с другими?
Другой разговор, если код сплеша менять нельзя... Тут уже придется шаманить.
А завязки с HWND окна соседнего процесса... ну Кодт прав — усложнение это. Ну да, ну да — сделать можно, ловкость рук и никакого мошенства, только зачем прикручивать такой уж "хитрый" костыль!?! Может действительно просто найти окно сплеша и мрачно сбросить ему HWND_TOPMOST?
В общем, ключевой вопрос: можно ли менять код сплеша?

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

C>Сенкс, но это не ко мне. Ни Висты, ни 7-ки под рукой нет. Народ, может кто проверит?

Я пользуюсь Win7 Ultimate x64. Что именно надо проверить?

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

W>

W>    MessageBox(NULL,"Device not ready. Please attach it and click OK","Not ready!", MB_OK |
W>                      MB_ICONINFORMATION|MB_TOPMOST);
W>

чет нафлужено, все нечитал, попробуйте поиграться с флагами
MB_APPLMODAL
MB_SYSTEMMODAL
MB_TASKMODAL
ченить да поможет, али любой поможет
вообще по идее MB_APPLMODAL уже должен решить проблемму.

M>MB_APPLMODAL
M>MB_SYSTEMMODAL
M>MB_TASKMODAL
M>ченить да поможет, али любой поможет
M>вообще по идее MB_APPLMODAL уже должен решить проблемму.
А если будет 2 MB_APPLMODAL диалога?
Вообще надо отучиваться от мнения что ваша прога самая главная у юзера. У среднего юзера в автозапуске с десяток софтин и если они начнут сплэши показывать... Я бы просто тупо грохнул мешающую прогу или написал бы софтину которая будет гасить ее сплэш если очень нужна именно эта прога.

P>Кажись в MessageBox первым аргументом можно передать хэндл на сплэш.

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

Лучший выход — самозахлапывающийся сплэш. по завершению загрузки, по таймеру или по клику мышки.
И нормальный парент у MessageBox, а не NULL.