Почему софт не соблюдает правило "откуда открыл - туда и направляй диалоги"? (4 стр) / Софт / Форум / Флейм / GameDev.ru

Ghost2
> Так то "на уровне ядра" в винде работают все диалоги и окна, если чего
и? Даже запись в фаил это уровень ядра, создание процесса/потока это тоже уровень ядра. Я тебе сразу сказал, это ты ломался.
> орхетектура пользовательского интерфейса винды
получение результата после работы диалога отрытия/сохранения файла к этому не относится, он тупо блокирует вызываемый поток и крутит свой диалог в другом пока блокируемый ждет. Если ты хочешь обойти это, то сам вынужден вызывать диалог в другом потоке блокировка которого допускается.
> Посмотрел winspy - окошко принадлежит тому же процессу. Наоткрывал рандомных приложений и везде окно диалога открытия/сохранения принадлежит тому же процессу, что и основное. Где ты обрел эти сакральные знания (которые не вера) про ядро и отдельные процессы?
да, там отдельный поток.
> И еще вопрос - как ты делаешь диалог открытия/сохранения модальным, если не задаешь ему родительское окно?

static OPENFILENAMEW file_params = {0};

file_params.lStructSize = sizeof(OPENFILENAME);
file_params.hwndOwner = 0;

диалог остается модальным, что не так?

Ghost2
Постоялец

#46
19:14, 9 июня 2025

Aroch

> Я тебе сразу сказал, это ты ломался
Ты сразу сказал, что конкретно эти диалоги особенные тем, что они выполняются «на уровне ядра». А получилось так, что там весь бэк выполняется на уровне ядра. Тогда твой акцент на этом перестал быть понятным еще больше.

> он тупо блокирует вызываемый поток и крутит свой диалог
И вызывающее окно вообще перестает получать сообщения?

> да, там отдельный поток
Ты же говорил, что отдельный процесс. И еще советовал почитать про это. Забыл что-ли?

> диалог остается модальным, что не так?
Если ты говоришь, что остается модальным, то все так. Я же на веру все принимаю, лол

Aroch
Постоялец

#47
0:01, 10 июня 2025

Ghost2
> И вызывающее окно вообще перестает получать сообщения?
если у тебя цикл приема сообщений в том же потоке то дагадайся с одного раза.
> Тогда твой акцент на этом перестал быть понятным еще больше.
обычные диалоги не создают и не блокируют вызываемый поток.
> Ты же говорил, что отдельный процесс
тут ошибся и исправился, сильно это изменило погоду?
> Я же на веру все принимаю, лол
так докажи обратное.

Dmitry_Milk
Постоялец

#48
7:52, 10 июня 2025

Aroch
> если у тебя цикл приема сообщений в том же потоке то дагадайся с одного раза.

С событиями пользовательского ввода понятно, раз диалог модальный, то нефиг. А вот насчет всяких WM_PAINT - если родительское окно вместе с модальным диалогом перекрыли окном другого процесса, а потом они снова стали видимыми - кто-то же должен перерисовать видимую часть родительского окна?

Не, понятно, что сейчас система может просто тупо помнить, что там было нарисовано до перекрытия, но если мы вернемся куда-нибудь в первую половину 90-х, во времена windows 3.x - модальные диалоги и messagebox уже были в винапи, но сохранять содержимое окна тогда был не вариант - WM_PAINT должен был работать для родительского окна даже во время MessageBox, DialogBox а также стандартных диалогов.

Aroch
Постоялец

#49
8:34, 10 июня 2025

Dmitry_Milk
> А вот насчет всяких WM_PAINT - если родительское окно вместе с модальным диалогом перекрыли окном другого процесса, а потом они снова стали видимыми - кто-то же должен перерисовать видимую часть родительского окна?
если дефолтный, то перерисует возможно. А если пользовательский то тебе надо как то принять сообщение через тот же PeekMessage и дернуть TranslateMessage и если они в том же потоке из которого ты вызвал диалог открытия окна, то сообщения тупо будут копиться.

Dmitry_Milk
Постоялец

#50
8:59, 10 июня 2025

Aroch
> А если пользовательский то тебе надо как то принять сообщение через тот же PeekMessage и дернуть TranslateMessage

Насколько я понимаю, вся бодяга с необходимостью как цикла сообщений так и WndProc, а не просто голой обработки сообщений сразу в цикле или наоборот, сразу прямой регистрации обработчика событий в ОС - именно ради возможности крутить цикл событий в разных местах.

В частности, если необходимо показать модальный диалог - DialogBox забирает управление у потока до закрытия диалога (то есть, основной цикл событий приложения не крутится), но вместо этого в своих кишках организует в своих кишках служебный цикл событий, который выборочно работает с очередью, обрабатывая полностью события только для диалога, но при этом имея возможность достать из очереди WM_PAINT (и возможно еще WM_TIMER и еще какой-то ограниченный набор) для всех остальных окон приложения и передать в DispatchMessage, который в свою очередь вызовет WndProc родительского окна (рекурсивно, потому что внешний вызов WndProc родительского окна все еще висит в стеке на обработке того события, в котором произошел вызов DialogBox).

Aroch
Постоялец

#51
9:30, 10 июня 2025

Dmitry_Milk
> в котором произошел вызов DialogBox
так никто не запрещает вызвать его вне.
> вызовет WndProc родительского окна
пользовательский? Ничего он не вызовет. Его даже может не быть. Ты можешь спокойно создать обычное консольное приложение и дергать openfile как обычно.

Dmitry_Milk
Постоялец

#52
10:37, 10 июня 2025

Aroch
> Его даже может не быть.

Я говорю про случай, когда родительское окно нуждается в обработке сообщений в тот момент, когда открыт модальный диалог (например, сообщения WM_PAINT для отрисовки родительского окна). Наличие модального диалога не блокирует обработку сообщений родительского окна полностью, несмотря на то, что поток заблокирован вызовом функции DialogBox/MessageBox и цикл событий приложения не работает.

Aroch
Постоялец

#53
11:20, 10 июня 2025

Dmitry_Milk
> когда родительское окно нуждается в обработке сообщений в тот момент
клиентские будут заблокированы. Если не будешь делать финты ушами.

Dmitry_Milk
Постоялец

#54
12:20, 10 июня 2025

Aroch
> клиентские

Я не знаю, что ты называешь "клиентскими" сообщениями. но суть в том, что блокировка потока функциями dialogbox/messagebox вовсе не обозначает, что очередь соообщений для родительского окна намертво блокируется при этом - некоторые сообщения все-таки попадают на обработку в wndproc "заблокированного" родительского окна.

Aroch
Постоялец

#55
13:22, 10 июня 2025

Dmitry_Milk
> Я не знаю, что ты называешь "клиентскими" сообщениями.
те что обрабатываются тобой.
> блокировка потока функциями dialogbox/messagebox
мне лень смотреть именно их. Но в одном ты прав некоторые сообщения будут таки обработаны что были посланы явно, типа WM_COMMAND, например приходят сообщения с тулбара. Я таким образом смог на вызывать пачку окон с открытием файла :) По хорошему посмотреть бы в каком потоке они выполняются при этом, так как я смог последовательно наоткрывать диалогов и они последовательно исполнили код реакции на открытие файла, что возможно либо при вызове из другого потока либо каких то махинаций со стеком.

Dmitry_Milk
Постоялец

#56
16:12, 10 июня 2025

Aroch
> что возможно либо при вызове из другого потока либо каких то махинаций со стеком.

Почему махинаций? Обычный стек вызовов, в котором просто перемежаются функции из приложения и системные:

          ------+                              -----+            -----+               -----+
         /     ...           -----+           /    ...          /    ...             /    ...
        /       |           /     |          /      |          /GetMessage(filtered)/ WndProc(dialog)
       /   GetMessage      /     ...        /CASE WM_COMMAND: /       |            /      ...
WinMain         |         /WndProc(MainWindow)       DialogBox      DispatchMessage        |           /
       \   DispatchMessage        |         \      ...        \      ...           \WndProc(MainWindow)
        \       |         \      ...         \      |          \      |             \      |           \
         \     ...         \      |           \     |           \     |              \    ...
          ------+           \     |            -----+            -----+               -----+

Все реализуемо в рамках одного потока, просто во время выполнения DialogBox/MessageBox вместо цикла событий из WinMain работает цикл фильтрованных событий внутри реализации DialogBox (ну или какой-то более общей для всех модальных).

UPD. Другими словами - как и при обычной работе окна, большую часть времени основной поток приложения заблокирован именно вызовом GetMessage (а не какой-то магией внутри DialogBox), просто этот GetMessage вызван не из WinMain, а из кишков DialogBox (или каких-то его более внутренних кишков).

122
Участник

#57
16:26, 10 июня 2025

1 frag / 2 deaths
> и... оказывается что он сохранил мне его вообще не туда, где я открыл изначальный файл. Неужели так трудно сделать
Ну а что ты хотел, блендер - бесплатная прога. Бесплатная == забили на удобство.
Я уже привык по папкам быстро ходить, с какого-то времени становится пофиг как только вырабатывается опыт в смене папок.

Aroch
Постоялец

#58
16:35, 10 июня 2025

Dmitry_Milk
> Обычный стек вызовов,
у меня на телефоне это выглядит сейчас как шар свиборга, но одно точно GetMessage/Dispatch c моей стороны не зовутся. OpenFileDialog запускается в отдельном потоке, это можно легко проверить в диспетчере задач. Я могу как нибудь потом просто в лог писать id потока из которого дергается код открытия файла, чтобы прояснить этот момент.

Dmitry_Milk
Постоялец

#59
17:01, 10 июня 2025

Aroch
> Я могу как нибудь потом просто в лог писать id потока из которого дергается код открытия файла, чтобы прояснить этот момент.

+ Это стопроцентно однопоточное приложение

− Скрыть

#include <windows.h>
#include <stdio.h>

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

int main()
{
    printf("main thread id: %d\n", GetCurrentThreadId());
    HINSTANCE hInstance = GetModuleHandle(0);

    WNDCLASS wc = {};

    wc.lpfnWndProc   = WindowProc;
    wc.hInstance     = hInstance;
    wc.hCursor       = LoadCursor(0, IDC_ARROW);
    wc.lpszClassName = "MY_WINDOW_CLASS";

    ATOM atom = RegisterClass(&wc);
    
    if ( atom == 0 ) {
        puts("RegisterClass error");
        return 0;
    }

    HWND hwnd = CreateWindowEx(
        0,                              // Optional window styles.
        wc.lpszClassName,               // Window class
        "Test main window",             // Window text
        WS_OVERLAPPEDWINDOW,            // Window style
        CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
        NULL,       // Parent window    
        NULL,       // Menu
        hInstance,  // Instance handle
        NULL        // Additional application data
    );

    if (hwnd == NULL) {
        puts("CreateWindow error");
        return 0;
    }

    ShowWindow(hwnd, SW_SHOWNORMAL);

    MSG msg = { };
    while (GetMessage(&msg, NULL, 0, 0) > 0)
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return 0;
}

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
        case WM_DESTROY:
            printf("WM_DESTROY in thread %d\n", GetCurrentThreadId());
            KillTimer(hwnd, 1);
            PostQuitMessage(0);
        return 0;
        
        case WM_CREATE:
            printf("WM_CREATE in thread %d\n", GetCurrentThreadId());
            SetTimer(hwnd, 1, 1000, 0);
        return 0;
        
        case WM_TIMER:
            printf("WM_TIMER in thread %d\n", GetCurrentThreadId());
        return 0;
        
        case WM_PAINT: {
            printf("WM_PAINT in thread %d\n", GetCurrentThreadId());
            PAINTSTRUCT ps;
            HDC hdc = BeginPaint(hwnd, &ps);

            FillRect(hdc, &ps.rcPaint, (HBRUSH) (COLOR_ACTIVECAPTION+1));

            EndPaint(hwnd, &ps);
        } return 0;

        case WM_KEYDOWN:
            printf("WM_KEYDOWN in thread %d\n", GetCurrentThreadId());
            MessageBox(hwnd, "Test", "test", MB_OK);
        return 0;
    }
    
    return DefWindowProc(hwnd, uMsg, wParam, lParam);
}