Re[17]: Переместить окно поверх других. - WIN API

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

W>Здравствуйте. Есть окно, чей хэндл мне известен. В общем случае оно может принадлежать другому процессу. Необходимо переместить окно поверх других (результат, аналогичный Alt + Tab-у на иконку данного приложения). Не могу подобрать WIN API функцию, которая бы дала нужный результат. Варианты, которые я попробовал:

Вариант 4: Не надо красть фокус ввода текущего приложения. НИКОГДА. Хочется привлечь внимание пользователя — "мигайте синим" в таскбаре, это абсолютно легально. Когда юзеру будет удобно — он переключится. Может, он сейчас пароль к фейсбуку набирает — а тут бац, и "I secretly love 50 cents" улетает в асечку.

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

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

VTT>>Легальный метод — это AllowSetForegroundWindow / SetForegroundWindow.
VTT>>Все остальные — это workaround / hack.
C>Почему? AttachThreadInput чем хак-то!?!
А тем, что пытается ввести систему в заблуждение, что пользователь осуществил ввод в этот процесс, и получить не причитающуюся ему привилегию на перенос окна на передний план.

C>>>По моему ВинРар так и делает, когда после фоновой архивации подымается из трея. Он там любопытно подымается, ему пофиг какое окно фореграунд, встает из трея и забирает фокус себе как делать нечего.
VTT>>Ничего такого рар не делает, после архивации окно висит на заднем плане.
C>Ну только что перепроверил (Вин7 х32, максимал). Всплыл как миленький из трея, и фокус себе захавал тоже. Причем поднялся он именно над Foregtound окном, а вовсе не оттуда откуда он запускался (Total Commander причем пущенный без админских прав)... Настораживает.

Ну только что перепроверил (Вин10 х64, про). Всплыл как миленький на заднем плане, и фокус себе не захватывал.

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

W>Как быть? Есть какой-то надежный способ "поднять" окно?

У меня вот такой код, вроде всегда работает:

    HWND hWndPopup = NULL;
    if(!IsWindowEnabled(hWnd))
        hWndPopup = GetWindow(hWnd, GW_ENABLEDPOPUP);
    if(hWndPopup)
    {
        SetForegroundWindow(hWndPopup);
        SetFocus(hWndPopup);
    }
    RestorePosition(hWnd, dwFlags);

// где
BOOL RestorePosition(HWND hWnd, DWORD dwFlags)
{
    BOOL bRes = FALSE;
    WINDOWPLACEMENT wp;
    wp.length = sizeof(WINDOWPLACEMENT);
        GetWindowPlacement(hWnd,&wp);
    if(wp.showCmd == SW_SHOWMINIMIZED || hWnd != app.m_hForeWnd) //GetForegroundWindow())
    {
        if((dwFlags & RP_KEEPMINIMIZED) == 0)
        {
            if(wp.showCmd != SW_SHOWMAXIMIZED)
            {
                bRes = ShowWindow(hWnd, SW_RESTORE);
                if(!bRes)
                    SendMessageTimeout(hWnd, WM_SYSCOMMAND, (WPARAM)SC_RESTORE, MAKELONG(0, -1), SMTO_ABORTIFHUNG, 100, NULL);
            }
        }
        if(dwFlags & RP_SHOWWINDOW)
        {
            bRes = ShowWindow(hWnd, SW_SHOW);    // to generate WM_WINDOWPOSCHANGED    // do not work, why?
            if(!bRes)
                SendMessageTimeout(hWnd, WM_SYSCOMMAND, (WPARAM)SC_RESTORE, MAKELONG(0, -1), SMTO_ABORTIFHUNG, 100, NULL);
        }

        SetForegroundWindow(hWnd);
        SendMessageTimeout(hWnd, WM_ACTIVATEAPP, (WPARAM)TRUE, 0, SMTO_ABORTIFHUNG, 100, NULL);
    }
    else
    {
        if((dwFlags & RP_MINIMIZEIFNORMAL) != 0)
        {
            HWND hWndNext = hWnd;
            while(hWndNext = GetWindow(hWndNext, GW_HWNDNEXT))
            {
                if(IsWindowVisible(hWndNext))
                    break;
            }
            bRes = ShowWindow(hWnd, SW_MINIMIZE);
            if(!bRes)
                SendMessageTimeout(hWnd, WM_SYSCOMMAND, (WPARAM)SC_MINIMIZE, MAKELONG(0, -1), SMTO_ABORTIFHUNG, 100, NULL);
            SendMessageTimeout(hWnd, WM_ACTIVATEAPP, FALSE, 0, SMTO_ABORTIFHUNG, 100, NULL);
            if(hWndNext != hWnd)
            {
                SetForegroundWindow(hWndNext);
                SendMessageTimeout(hWndNext, WM_ACTIVATEAPP, TRUE, 0, SMTO_ABORTIFHUNG, 100, NULL);
            }
        }
        else if(wp.showCmd == SW_SHOWMAXIMIZED)
        {
            ShowWindow(hWnd, SW_SHOWMAXIMIZED);
        }
    }

    return TRUE;
}

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

C>Это очень яркий пример: как делать не надо. Понятно что для Васьки-механика-сантехника должен быть "скрытый люк", чтобы "прочистить трубы", если очень надо. Но вообще все это для пользователя, поэтому нужно делать вещи, которые хотя бы видны, как-то индицируются, проявляются на экране, имееют обратную связь.

Мне кажется, что все эти вещи опять упираются в старый добрый Микрософт. Последний раз, когда я NT4 устанавливал, я сидел и смотрел череду файлов, которые инсталлятор копировал. 7-ка к тому времени вышла уже, я сидел и тут же в голове сравнивал 7-ку и эти файлы. И мне было по-доброму жалко 4-ку

у неё в наборе такой аскетичный наивный минимум, что казалось, её вечерами собрали десять талантливых студентов (а может так оно и было, хотя её живучесть говорит о том, что это были не студенты точно). И сейчас я думаю, что НТя родилась уже достаточно давно, в те же времена надо было знать консольный ms-dos, такой же (другого не было) unix, надо было помнить все эти команды наизусть. Поэтому, как мне кажется, ребята из Микрософта больше заботились о функционале, чем о том, насколько они должно быть интуитивно понятно, потому что винда была больше рассчитана на нас, IT-шников, чем на простых юзеров. Расчёт был на то, что пользователи буду читать маны, если хотят научиться. Линупсоиды до сих пор так делают. Поэтому много что могло ускользнуть, я про копирование из Msg узнал тоже не более 5 лет назад, тоже случайно, хотя про shift-f10 знал ещё с 90-х (у меня за спиной стоял наш рабочий файловый сервер, у которого сломалась/потерялась мышь, а кнопки "меню" тогда в клавиатурах ещё не было). Теперь всё по-другому, но старый функционал и GUI никто трогать уже не будет, да и это хорошо, потому что новый GUI это какой-то наркоманский приход

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

C>PS: попробовал я эти шифты с пробелами да энтерами. Не спорю, наверное должно работать. Ну у меня какая-то хрень началась, зебатец с гуглом начали чего-то окошками жонглирить
Ооот! Потому что все эти их программеры msdn-ов не читали!

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

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

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

W>>>Как быть? Есть какой-то надежный способ "поднять" окно?
GZ>>Если ты сам в foreground, тогда чтобы более менее гарантированно необходимо вызвать AllowSetForegroundWindow на процесс. А дальше пусть он дальше кувыркается. Остальные способы более похожи на танцы с бубном.
W>Ничего не меняется, окно все равно не "всплывает". Да эти Foreground уже сами по себе танцы с бубном, ИМХО. Зачем мне делать какое-то окно foreground, мне нужно просто "альт-табнуть" указанный процесс.

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

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

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

C>>Что вообще нужно-то?
C>>Просто отфореграундиться над произвольным окном и забрать фокус себе
W>This. Но я уже понял ошибочность своих рассуждений, спасибо.

Ну если действительно нужно привлечь внимание, то
а) Можно позвать FlashWindow(Ex)

б) Не надолго сделать свое окно TopMost. Но это бабушка надвое сказала. Топмост-окна вот это действительно зло. К тому же не годится если оно полноэкранное или развернутое. Представьте себе, бац ~~вторая смена~~ полностью меняется контекст пользовательского внимания. Только что на экране было одно, а упс и уже полностью другое. Так не стоит. Совершенно точно.

в) Если и делать топмост, то ненадолого. 3 секунды и обратно прячемся. Молодой ЗеБат крайне уважал свой сплешскрин (заставка при запуске) вешать топмостом, пока он грузится. Млин! Как же это в нем достало. Только мешает — хотя и не долго.

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

д) Ну в принципе можно еще и окошком, если оно только не развернутое поблинковать. По-мерцать в общем. Тут вариантов масса: секунды три скрыть\показать свое окно, можно менять фон окна так же в цикле стандартный\какой-нить яркий типа красный (опять же секунды 3 и 2-3 итерации и закончили).

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

Все эти «мерцания» делаются в фоновом потоке, чтобы не блокировать основной.

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

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

W>Здравствуйте, Carc, Вы писали:
C>>Можно прицепить к вводу foreground-окна, используя AttachThreadInput и только потом всплывать через SetForegroundWindows.
W>Task Switcher так и делает?
Вопросы по делу:

А что такое Task Switcher?
А что он делает?
А как он это делает?
А он говорит нам "что он сделает это с нами" (ц)?
А почему я не телепат?

Что вообще нужно-то?
Просто отфореграундиться над произвольным окном и забрать фокус себе или что-то другое?

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

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

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

C>Почему не удастся-то!?! AttachThreadInput к окну, которое сейчас на переднем плане, т.е. то, которое GetForegroundWindow, и если AttachThreadInput завершилась успешно, то тогда поехали. И должно сработать.
C>Другой разговор, что прям щаззз (ц) вся окна подряд, а вернее потоки, которым принадлежат окна, так вам и разрешат цепляться к их очереди ввода (AttachThreadInput).

Легальный метод — это AllowSetForegroundWindow / SetForegroundWindow.
Все остальные — это workaround / hack.
Но тс они явно не к чему.

C>По моему ВинРар так и делает, когда после фоновой архивации подымается из трея. Он там любопытно подымается, ему пофиг какое окно фореграунд, встает из трея и забирает фокус себе как делать нечего.
Ничего такого рар не делает, после архивации окно висит на заднем плане.

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

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

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

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

VTT>>>>Легальный метод — это AllowSetForegroundWindow / SetForegroundWindow.
VTT>>>>Все остальные — это workaround / hack.
C>>>Почему? AttachThreadInput чем хак-то!?!
VTT>>А тем, что пытается ввести систему в заблуждение, что пользователь осуществил ввод в этот процесс, и получить не причитающуюся ему привилегию на перенос окна на передний план.
C>Бред. Если ему не положены привилегии, то AttachThreadInput завершится неудачей, и ничего не выйдет. А система не должна зависеть от того, пытается ли ее кто-нить ввести в заблуждение, или еще чего куда ввести. Нет привилегий — и не сработает. Никто и не спорил.

C>>>>>По моему ВинРар так и делает, когда после фоновой архивации подымается из трея. Он там любопытно подымается, ему пофиг какое окно фореграунд, встает из трея и забирает фокус себе как делать нечего.
VTT>>>>Ничего такого рар не делает, после архивации окно висит на заднем плане.
C>>>Ну только что перепроверил (Вин7 х32, максимал). Всплыл как миленький из трея, и фокус себе захавал тоже. Причем поднялся он именно над Foregtound окном, а вовсе не оттуда откуда он запускался (Total Commander причем пущенный без админских прав)... Настораживает.

C>Я уже писал, что проверял на своем коде. Мое приложение работало из под ограниченной учетки, соседние приложения по разному. Мой код всплывания дергался каждые полторы секунды. Дык вот ессесна над приложениями с более высокими правами мое добро и не всплывало, ибо
C>AtttachThreadInput заканчивался неудачей. Что ожидаемо, и я изначально это описал.

Воу воу, полешче, хватит лепить мне минусы. У вас же сплошной винигрет.
Привилегия в данном случае — это возможность отправить окно на передний план или передать такую возможность другому процессу.
А не "запущенность с правами администратора" или какая другая системная привилегия.
О взаимодействия с процессами, запущенными из-под привилегированных пользователей и к которым могут применяться методы изоляции, тут речи вообще не шло.

C>Но сам способ с AttachThreadInput вовсе не хак, а официальный API.
Это официальный API, но его использование для обхода ограничений SetForegroundWindow — это если и не хак, то наглый workaround.
Если окно не на переднем плане и SetForegroundWindow не работает, то оно так и должно сидеть дальше и ждать, пока пользователь сам в него переключится.
Как максимум, оно может вызвать FlashWindow чтобы привлечь внимание пользователя.

VTT>>Ну только что перепроверил (Вин10 х64, про). Всплыл как миленький на заднем плане, и фокус себе не захватывал.
C>Над кем не всплыл? Надо всеми подряд и не должен всплывать.
Да ни над кем не всплыл.

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

VTT>>Легальный метод — это AllowSetForegroundWindow / SetForegroundWindow.
VTT>>Все остальные — это workaround / hack.
C>Почему? AttachThreadInput чем хак-то!?!

Да просто потому что Вы своими грязными сапогами топчете очередь ввода процесса-жертвы.
Вы никогда не наблюдали странных эфектов после такого AttachThreadInput? Магическое пропадание фокуса у жертвы, даже после Вашего всплытия/погружения? Потеря состояния клавиатуры? Частичная потеря ввода? Неожиданный "Enter" Вашей кнопке "ОК" до того, как жертва осознала потерю фокуса и прочитала Ваше наиважнейшее сообщение?
Это здорово, если Вы один "такой умный"; а если я тоже пытаюсь украсть фокус?
Такое поведение объяснимо у pop-over adware, но не у уважающего себя приложения.

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

VF>Такое поведение объяснимо у pop-over adware, но не у уважающего себя приложения.
Это так же подходит для task management приложений

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

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

VF>>Такое поведение объяснимо у pop-over adware, но не у уважающего себя приложения.
CEM>Это так же подходит для task management приложений

Так это и есть Adware-приложения, как впрочем и сам Проводник Windows. Легитимны только поделки вроде Блокнота Windows. Ничего такого в эдаком духе: никаких субклассов — ай-яй-яй, хуки, даже на собственный поток — ни в коем случае, DLL инжект даже и не думать (все эти Лингвы, ДропБоксы которые вешают свои ДЛЛ куда ни попадя — просто вне закона). Службы — да вы в своем уме? Драйвера — да как только посметь решили?

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

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

CEM>>><ctrl>+<esc>, <esc>, <tab>, <tab>, несколько <->>, <ентер!>

C>>И что это даст-то!?! Окна же говорю, нет в Alt+Tab, так оно де факто скрыто (ShowWindow+SW_HIDE), и есть только иконкой в трее.
CEM>Вот ты же не попробовал проверить?

CEM>Ты плохо знаешь старый добрый Микрософт

Эти ребята делали весь свой софт обязательно с учётом того, что в любое место можно попасть без мыша. Если ты по выше приведённой инструкции попал трей, то:
CEM><ентер>/<пробел> — это левая кнопка мыши на иконке/дефолтное действие(как и везде). Многим программам хватает этого, чтобы показаться наружу. Например, таск манагер, у которого hide minimized on.
CEM><shift>-<F10> — правая мыша на иконке(как и везде), контекстное меню. Это для тех приложений, кому мало левой кнопки мыши.
CEM>Стало быть, всё что можно сделать мышью в трейбаре — можно сделать с клавиатуры

Это не очевидно… Нормальный среднестатистический юзерок обильно встречающийся в среднерусской полосе России об этом понятия не имеет.
Я же о другом. Окна на экране нет, оно скрыто и есть только иконка в трее, но само окно есть в списке Alt+Tab. Вот это для него привычно! Как это делается разговор другой…

А все эти скрытые команды да хаки, она как раз для нашего оппонента больше. Я с виндой наверное лет так 25 знаком уже. Хотя что Ctrl+C на стандартном MessageBox скопипастит в буфер обмена евойное содержание узнал наверное с год или два назад. К вопросу о скрытых и неочевидных командах. Казалось бы должен знать, ан нет. А была б хоть какая индикация, да хоть тултип про Ctrl+C в иконке в том же MesssageBox — и проблем бы не было. Все б знали и пользовались.

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

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

Здравствуйте. Есть окно, чей хэндл мне известен. В общем случае оно может принадлежать другому процессу. Необходимо переместить окно поверх других (результат, аналогичный Alt + Tab-у на иконку данного приложения). Не могу подобрать WIN API функцию, которая бы дала нужный результат. Варианты, которые я попробовал:

1. ShowWindow(hwnd, SW_RESTORE);
Это работает для случая, если окно свернуто, для окна, которое накрыто другим окном, ничего не происходит по-моему.

2. SetForegroundWindow(hwnd);
Это работает почти всегда, кроме одного важного случая. У меня два инстанса одного приложения — два одинаковых окна накладываются точно одно поверх другого. Если нижнее приложение пытается "всплыть" при помощи этой функции, таскбар активируется, нужное приложение становится "синим" (ну, якобы получает фокус), но само окно остается накрытым старым окном.

3. BringWindowToTop(hwnd);
Вообще ничего не делает.

Как быть? Есть какой-то надежный способ "поднять" окно?

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

W>Как быть? Есть какой-то надежный способ "поднять" окно?
Если ты сам в foreground, тогда чтобы более менее гарантированно необходимо вызвать AllowSetForegroundWindow на процесс. А дальше пусть он дальше кувыркается. Остальные способы более похожи на танцы с бубном.

Здравствуйте, Went, Вы писали:
…
W>Как быть? Есть какой-то надежный способ "поднять" окно?
Можно прицепить к вводу foreground-окна, используя AttachThreadInput и только потом всплывать через SetForegroundWindows.

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

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

W>>Как быть? Есть какой-то надежный способ "поднять" окно?
GZ>Если ты сам в foreground, тогда чтобы более менее гарантированно необходимо вызвать AllowSetForegroundWindow на процесс. А дальше пусть он дальше кувыркается. Остальные способы более похожи на танцы с бубном.
Ничего не меняется, окно все равно не "всплывает". Да эти Foreground уже сами по себе танцы с бубном, ИМХО. Зачем мне делать какое-то окно foreground, мне нужно просто "альт-табнуть" указанный процесс.

Здравствуйте, Carc, Вы писали:
C>Можно прицепить к вводу foreground-окна, используя AttachThreadInput и только потом всплывать через SetForegroundWindows.
Task Switcher так и делает?

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

MD>Вариант 4: Не надо красть фокус ввода текущего приложения. НИКОГДА.
Никогда не говори "никогда"

А если человек пишет свой таскбар или иной таск манагер?

MD>Хочется привлечь внимание пользователя — "мигайте синим" в таскбаре, это абсолютно легально.

FlashWindowEx

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

W>Как быть? Есть какой-то надежный способ "поднять" окно?

Ну ещё можно SetWindowPos попробовать.

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

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

W>>Как быть? Есть какой-то надежный способ "поднять" окно?

ES>Ну ещё можно SetWindowPos попробовать.
А чего оно даст-то для "альт-табнуть окно" по выражанию топик-стартера?

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

VTT>Если оба экземпляра приложения не находятся на переднем плане, то перейти на передний план (легальными методами) не удастся.
Почему не удастся-то!?! AttachThreadInput к окну, которое сейчас на переднем плане, т.е. то, которое GetForegroundWindow, и если AttachThreadInput завершилась успешно, то тогда поехали. И должно сработать. По моему ВинРар так и делает, когда после фоновой архивации подымается из трея. Он там любопытно подымается, ему пофиг какое окно фореграунд, встает из трея и забирает фокус себе как делать нечего.

Другой разговор, что прям щаззз (ц) вся окна подряд, а вернее потоки, которым принадлежат окна, так вам и разрешат цепляться к их очереди ввода (AttachThreadInput).

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

VTT>Легальный метод — это AllowSetForegroundWindow / SetForegroundWindow.
VTT>Все остальные — это workaround / hack.
Почему? AttachThreadInput чем хак-то!?!
Не спорю, что там много чего для нее понадобится. Ну та же OpenThread к чужому потоку, а она ну прям таки сразу всё и открыла. Запросто не отдаст хендл чужого потока. И соответственно схема просто не сработает. Но это вопрос чуток другой плоскости.

VTT>Но тс они явно не к чему.

C>>По моему ВинРар так и делает, когда после фоновой архивации подымается из трея. Он там любопытно подымается, ему пофиг какое окно фореграунд, встает из трея и забирает фокус себе как делать нечего.
VTT>Ничего такого рар не делает, после архивации окно висит на заднем плане.
Ну только что перепроверил (Вин7 х32, максимал). Всплыл как миленький из трея, и фокус себе захавал тоже. Причем поднялся он именно над Foregtound окном, а вовсе не оттуда откуда он запускался (Total Commander причем пущенный без админских прав)... Настораживает.

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

VTT>Легальный метод — это AllowSetForegroundWindow / SetForegroundWindow.
VTT>Все остальные — это workaround / hack.
Ну вот вам функция, которая дергается по таймеру. Всплывает мое окно как миленькое, и фокус себе забирает у кого хочешь. Но как говорил, все будет зависеть от прав: если успешно отработает AttachThreadInput к чужому потоку.

    const HWND hwnd=::GetForegroundWindow();//кто у нас фореграунд-окно сейчас

    DWORD pid =0;
    
    //получаем ThreadID и ProcessID окна на переднем плане
    const DWORD tid=::GetWindowThreadProcessId(hwnd,&pid);

    //если окно переднего плана и так наше, ту хулио нам хулио (ц) - мы и без атача всё можем
    if (GetCurrentProcessId() == pid)
        return;
    
    //подключаемся к очереди ввода, но тут могет быть неудача - из-за безопасности Windows    
    if (AttachThreadInput(GetCurrentThreadId(), tid,TRUE)) {
        //ага, мль подключилися значитъ - ну поехали тогда
        ::SetForegroundWindow(m_hWnd);//m_hWnd - это HWND нашего окна, откуда по по таймеру для теста дергается эта функция
        ::SetActiveWindow(m_hWnd);
        ::SetFocus(m_hWnd);
        //отключаемся от очереди ввода к чужому окошецу
        AttachThreadInput(GetCurrentThreadId(), tid,FALSE);
    }

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

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

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

VTT>>>Легальный метод — это AllowSetForegroundWindow / SetForegroundWindow.
VTT>>>Все остальные — это workaround / hack.
C>>Почему? AttachThreadInput чем хак-то!?!
VTT>А тем, что пытается ввести систему в заблуждение, что пользователь осуществил ввод в этот процесс, и получить не причитающуюся ему привилегию на перенос окна на передний план.
Бред. Если ему не положены привилегии, то AttachThreadInput завершится неудачей, и ничего не выйдет. А система не должна зависеть от того, пытается ли ее кто-нить ввести в заблуждение, или еще чего куда ввести. Нет привилегий — и не сработает. Никто и не спорил. Но сам способ с AttachThreadInput вовсе не хак, а официальный API.

C>>>>По моему ВинРар так и делает, когда после фоновой архивации подымается из трея. Он там любопытно подымается, ему пофиг какое окно фореграунд, встает из трея и забирает фокус себе как делать нечего.
VTT>>>Ничего такого рар не делает, после архивации окно висит на заднем плане.
C>>Ну только что перепроверил (Вин7 х32, максимал). Всплыл как миленький из трея, и фокус себе захавал тоже. Причем поднялся он именно над Foregtound окном, а вовсе не оттуда откуда он запускался (Total Commander причем пущенный без админских прав)... Настораживает.

VTT>Ну только что перепроверил (Вин10 х64, про). Всплыл как миленький на заднем плане, и фокус себе не захватывал.
Над кем не всплыл? Надо всеми подряд и не должен всплывать.
Я уже писал, что проверял на своем коде. Мое приложение работало из под ограниченной учетки, соседние приложения по разному. Мой код всплывания дергался каждые полторы секунды. Дык вот ессесна над приложениями с более высокими правами мое добро и не всплывало, ибо
AtttachThreadInput заканчивался неудачей. Что ожидаемо, и я изначально это описал.

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

C>А чего оно даст-то для "альт-табнуть окно" по выражанию топик-стартера?

Ну вроде же она меняет z-order у окон.

C>>Но сам способ с AttachThreadInput вовсе не хак, а официальный API.
VTT>Это официальный API, но его использование для обхода ограничений SetForegroundWindow — это если и не хак, то наглый workaround.
VTT>Если окно не на переднем плане и SetForegroundWindow не работает, то оно так и должно сидеть дальше и ждать, пока пользователь сам в него переключится.
VTT>Как максимум, оно может вызвать FlashWindow чтобы привлечь внимание пользователя.
Мы обсуждали способ решения, а вовсе не юзабилити. Что оно там должно или не должно — решать топик-стартеру, тем более что он не очень то внятно пояснил, чего ему по сути надо. Особенно настараживает фраза "мне всего лишь нужно альтабнуть окно".

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

Я имею ввиду именно пользовательские действия, что все таки пользователь именно что сам нажмет Alt+Tab, дальше уже софтино само все сделает. Но обратите внимание на посылку: пользователь жмёт Альт+Таб сам — т.е. сначала ручками делает нужному окну foreground, а только потом...

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

Но разговор то изначальный о другом был... О способах, а не о практиках, и их достоинствах и недостатках (ВинРар кстати иногда мешает такой своей премудростью, хотя и впечатляет).

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

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

C>>А чего оно даст-то для "альт-табнуть окно" по выражанию топик-стартера?

ES>Ну вроде же она меняет z-order у окон.
Foreground от этого наше окно не станет.

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

C>Foreground от этого наше окно не станет.

В ремарках об этом написано

If an application is not in the foreground, and should be in the foreground, it must call the SetForegroundWindow function.
To use SetWindowPos to bring a window to the top, the process that owns the window must have SetForegroundWindow permission.

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

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

C>>Foreground от этого наше окно не станет.

ES>В ремарках об этом написано
ES>

ES>If an application is not in the foreground, and should be in the foreground, it must call the SetForegroundWindow function.
ES>To use SetWindowPos to bring a window to the top, the process that owns the window must have SetForegroundWindow permission.

Причем тут это? Если в данный момент наш процесс не имеет foreground-окна, если foreground-окно где-то в другом процессе, то это не поможет…

Здравствуйте, VTT. Спасибо большое, осознал всю глубину проблематики

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

C>

А что такое Task Switcher?
Окно, всплывающее по Atl+Tab-у у винду

C>

А что он делает?
C>

А как он это делает?
C>

А он говорит нам "что он сделает это с нами" (ц)?
C>

А почему я не телепат?

C>Что вообще нужно-то?
C>Просто отфореграундиться над произвольным окном и забрать фокус себе
This. Но я уже понял ошибочность своих рассуждений, спасибо.

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

W>>>Как быть? Есть какой-то надежный способ "поднять" окно?
GZ>>Если ты сам в foreground, тогда чтобы более менее гарантированно необходимо вызвать AllowSetForegroundWindow на процесс. А дальше пусть он дальше кувыркается. Остальные способы более похожи на танцы с бубном.
W>Ничего не меняется, окно все равно не "всплывает". Да эти Foreground уже сами по себе танцы с бубном, ИМХО. Зачем мне делать какое-то окно foreground, мне нужно просто "альт-табнуть" указанный процесс.
Ну к примеру из бубны из закромов — вывоз ворда на первый план:

                System.Windows.Forms.IWin32Window foregroundWindow = Win32.GetForegroundWindow();
                _wordApp = new Application();
                _wordApp.Visible = true;
                _doc = _wordApp.Documents.Open(_startEditData.FilePath);
                var fullNameOld = _doc.FullName;
                //Показываем Word поверх всех приложений.
                try
                {
                    System.Windows.Forms.Form form = new System.Windows.Forms.Form();
                    form.Opacity = 0d;
                    form.ShowInTaskbar = false;
                    form.Shown += new EventHandler((object o, EventArgs e) =>
                    {
                        try
                        {
                            string caption = string.Format("{0} - {1}", Path.GetFileName(_startEditData.FilePath), _wordApp.Caption);
                            IntPtr hWnd = FindWindow("OpusApp", caption);
                            SetForegroundWindow(hWnd);
                        }
                        finally
                        {
                            form.Close();
                        }
                    });
                    form.ShowDialog(foregroundWindow);
                }
                catch { }

Тут уже указывали про AttachedTheadInput — этот бубен был у нас реализован, но на него приходили нарекания. При какмх-то непонятных условиях, с непонятным сервис паком он периодически не работал. Локализовать почему и в чем зависимость — не удалось. Вышеописанный способ тоже не 100 процентный, но оказался более работоспособный.

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

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

VTT>>>Легальный метод — это AllowSetForegroundWindow / SetForegroundWindow.
VTT>>>Все остальные — это workaround / hack.
C>>Почему? AttachThreadInput чем хак-то!?!

VF>Да просто потому что Вы своими грязными сапогами топчете очередь ввода процесса-жертвы.
VF>Вы никогда не наблюдали странных эфектов после такого AttachThreadInput?
Нет, не наблюдал. С чего там быть магическим эффектам?
VF>Магическое пропадание фокуса у жертвы, даже после Вашего всплытия/погружения?
Дык про то и речь была, что фокус ввода забрать. Вопрос стоит ли это делать несколько из другой области.
VF>Потеря состояния клавиатуры? Частичная потеря ввода? Неожиданный "Enter" Вашей кнопке "ОК" до того, как жертва осознала потерю фокуса и прочитала Ваше наиважнейшее сообщение?
Ну а это еще откуда вдруг? С какой перепуга наш Enter отправляется в чужой поток? Если делать аккуратно, то ничего никуда не отправится. Приатачились, всплыли, забрали фокус и тут же отдетачались обратно. С какого вдруг наш Enter пойдет в чужой поток. Это что за бубны с танцем такие? Если мы приатачивались в оконном потоке, то никакой Enter не должен обрабатываться у нас, пока мы не завершим танцы с AttachThreadInput. Если в соседнем потоке, то тем более откуда из нашего оконного потока пойдет Enter в чужой поток, если оконный то поток как раз и вовсе не атачился.

VF>Это здорово, если Вы один "такой умный"; а если я тоже пытаюсь украсть фокус?
VF>Такое поведение объяснимо у pop-over adware, но не у уважающего себя приложения.
Ну уже написано выше, что удобство такого решения достаточно спорно. Тот же ВинРар так делает судя по всему, и это несколько ставит в тупик. Но тем не менее у него все работает — фокус забирается. Причем он явно не использует SwitchToWindow и прочие недокументированные функции.

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

VF>>Такое поведение объяснимо у pop-over adware, но не у уважающего себя приложения.
CEM>Это так же подходит для task management приложений

task management приложения инициируются пользователем; в таком случае НЕТ проблем с выходом на foreground.

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

VF>task management приложения инициируются пользователем; в таком случае НЕТ проблем с выходом на foreground.
Не совсем так... Попробуйте-ка поднять свое приложение из трея клавиатурой стандартненько в стиле Alt+Tab, когда окно "упавшее" в трей скрыто… Его попросту не будет в списке окон по Alt+Tab и приходится "шаманить". Вот тут вот AttachThreadInput и пригодится

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

VF>task management приложения инициируются пользователем; в таком случае НЕТ проблем с выходом на foreground.

Ну, так-то, любое, запущенное приложение инициируется пользователем...

Я думаю, надо так: если пользователь сам, своими действиями хочет сделать foreground — надо сделать foreground, например, по горячей кнопке поднять окно заметки, чтобы потом там что-то вбить — тут нехорошо заставлять юзера ещё кликать/алть-табить в это окно.
Иначе топ/топмост/флеш и прочее, но фокус окну не давать. А то так-то да, было как-то, что-то не глядя (в экран) вбиваешь, и краем глаза замечаешь, что какое-то окно мелькнуло

VF>>task management приложения инициируются пользователем; в таком случае НЕТ проблем с выходом на foreground.
C>Не совсем так... Попробуйте-ка поднять свое приложение из трея клавиатурой стандартненько в стиле Alt+Tab, когда окно "упавшее" в трей скрыто… Его попросту не будет в списке окон по Alt+Tab и приходится "шаманить". Вот тут вот AttachThreadInput и пригодится

<ctrl>+<esc>, <esc>, <tab>, <tab>, несколько <->>, <ентер!>

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

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

VF>>task management приложения инициируются пользователем; в таком случае НЕТ проблем с выходом на foreground.

CEM>Ну, так-то, любое, запущенное приложение инициируется пользователем...

CEM>Я думаю, надо так: если пользователь сам, своими действиями хочет сделать foreground — надо сделать foreground, например, по горячей кнопке поднять окно заметки, чтобы потом там что-то вбить — тут нехорошо заставлять юзера ещё кликать/алть-табить в это окно.
CEM>Иначе топ/топмост/флеш и прочее, но фокус окну не давать. А то так-то да, было как-то, что-то не глядя (в экран) вбиваешь, и краем глаза замечаешь, что какое-то окно мелькнуло

Ну а я про что!?! А тут товарисч "хак, хак, энтер у него нитуда ушел"

VF>>>task management приложения инициируются пользователем; в таком случае НЕТ проблем с выходом на foreground.
C>>Не совсем так... Попробуйте-ка поднять свое приложение из трея клавиатурой стандартненько в стиле Alt+Tab, когда окно "упавшее" в трей скрыто… Его попросту не будет в списке окон по Alt+Tab и приходится "шаманить". Вот тут вот AttachThreadInput и пригодится

CEM><ctrl>+<esc>, <esc>, <tab>, <tab>, несколько <->>, <ентер!>

И что это даст-то!?! Окна же говорю, нет в Alt+Tab, так оно де факто скрыто (ShowWindow+SW_HIDE), и есть только иконкой в трее.

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

CEM>><ctrl>+<esc>, <esc>, <tab>, <tab>, несколько <->>, <ентер!>

C>И что это даст-то!?! Окна же говорю, нет в Alt+Tab, так оно де факто скрыто (ShowWindow+SW_HIDE), и есть только иконкой в трее.
Вот ты же не попробовал проверить?

Ты плохо знаешь старый добрый Микрософт

Эти ребята делали весь свой софт обязательно с учётом того, что в любое место можно попасть без мыша. Если ты по выше приведённой инструкции попал трей, то:
<ентер>/<пробел> — это левая кнопка мыши на иконке/дефолтное действие(как и везде). Многим программам хватает этого, чтобы показаться наружу. Например, таск манагер, у которого hide minimized on.
<shift>-<F10> — правая мыша на иконке(как и везде), контекстное меню. Это для тех приложений, кому мало левой кнопки мыши.
Стало быть, всё что можно сделать мышью в трейбаре — можно сделать с клавиатуры

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

CEM> Теперь всё по-другому, но старый функционал и GUI никто трогать уже не будет, да и это хорошо, потому что новый GUI это какой-то наркоманский приход

Да уж! У них полный звиздец с интерфейсом теперь. Одно слово — ублюдочный. Где индикация? Где "все под рукой", ну вроде если есть какая-то dockable панель, то закрыть ее можно было бы быстро: тот же крестик + контекстное меню с основными делами. А что видим? Крестика как всегда нет. В меню что угодно, включая ссылку на настройку персонализациии, аэры и прочия. У историков только два вопроса: нахера и нахера?
Если я админ\девелопер, то я до вашей персонализации и сам доберусь когда понадобится. Если нет, то простому юзеру зачем это авно? Он не будет ничего перенастраивать, ибо не сечет. А вот панель куда-нить выкинуть я не могу. Ну о чем говорить-то? Индусы явно делали: это уже не дизайн, это "гламур". Красиво, анимировано — но бесполезно!!!

И главное у них все равно не получится: нельзя сделать инструмент одинаково хороший для всего: и для телефона, и для инета, и для нормальной работы. И швейцарский нож тут не причем! Это не инструмент, это «зубочистка» такая. Как зубочистка он и вправду хорош и универсален, но ни как инструмент.

Про UI\UX в винде все видно. Алан Купер от них ушел и сразу виден результат индусцов. А вообще NT не мальчики писали. Если там в ядре покопаться, понять задумку, реализацию — то видно, что и задумано красиво, и сделано красиво. А то что файлов мало, дык "совершенство это когда нечего убрать, а не нечего добавить". А теперь прикинь: все это было сделано в 93-95 годах.

Отсебю_на_заметку: казалось бы NT 4 sp6, секурность, сервисы, Unicode все дела. Дык вот эта “девачка” летала на машине куда как быстрее и уж точно надежнее, чем 98-ая винда. Внимание: машинка P-150, 16 MB ОЗУ. Повторяю по слогам: пентиум-150 (даже не пень-2), 16 метров (метров, метров, не гигов) оперативки.

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

C>И главное у них все равно не получится: нельзя сделать инструмент одинаково хороший для всего: и для телефона, и для инета, и для нормальной работы. И швейцарский нож тут не причем! Это не инструмент, это «зубочистка» такая. Как зубочистка он и вправду хорош и универсален, но ни как инструмент.

Вот у меня вопрос по этой теме, на который у меня ответа пока нет. Все мы программисты, и буквально во втором классе школы нас учат отделять интерфейс от функционала. Попытки кастомизировать интерфейс винды начались ещё с WindowsME, у неё внутри были штатные средства изменения внешнего вида. Вопрос: почему до сих пор они(MS) так и не смогли сделать так, чтобы UI винды менялся быстро и просто? До сих пор в персонализации только цвета (в 10-ке даже размеры спрятали. А, да, и цвет оставили только один) и картинки на рабочий стол. Единственной причиной вижу устройство user32.dll в частности и всей внутренней системы GUI вообще. Таки ребята из группы NT по непонятным причинам свалили всё в кучу и усложнили, видимо, в угоду хорошей производительности, не знаю. В результате влезть внутрь и отделить интерфейс от реализации стало сильно сложно. Единственные, кто более-менее смог закостамизировать винды, была StarDocks. Мы в своё время на работе изрядно потанцевали с бубнами, чтобы сделать примерно то же.

Вот если бы MS разделило функционал и UI, можно было бы отрубать этот унылый веб-интерфейс и включать нормальный семёрочный. Да даже просто, без переключения, можно было собрать десктопную винду с нормальным интерфейсом, а планшетную — с коробками. Не понимаю, почему так не было сделано.

	От:	Mr.Delphist
	Дата:	02.11.16 16:08
	Оценка:	2 (1) +4

От:	VTT	http://vtt.to
Дата:	03.11.16 10:13
Оценка:	+2 -1

	От:	CEMb
	Дата:	03.11.16 13:47
	Оценка:	6 (2)

	От:	CEMb
	Дата:	14.11.16 13:39
	Оценка:	8 (1)

От:	VTT	http://vtt.to
Дата:	03.11.16 08:57
Оценка:	6 (1)

От:	Carc	https://vk.com/gosha_mazov
Дата:	03.11.16 13:09
Оценка:	4 (1)

	От:	Evgeniy Skvortsov
	Дата:	03.11.16 07:37
	Оценка:

	От:	VladFein
	Дата:	08.11.16 01:24
	Оценка:	-1

	От:	VladFein
	Дата:	10.11.16 17:58
	Оценка: