Есть диалоговое окно Excel. Я знаю его хэндл.
А как определить хэндл какого-нибудь элемента этого диалога.
GetDlgItem не работает. Вернее работает, но не для все контролов.
Есть в диалоге поля ввода, итх хендлы определяются. А вот хэндлы
кнопок и т.д. не определяются.
В чем дело? Причем, это во многих приложениях.

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

А>Есть диалоговое окно Excel. Я знаю его хэндл.
А>А как определить хэндл какого-нибудь элемента этого диалога.
А>GetDlgItem не работает. Вернее работает, но не для все контролов.
А>Есть в диалоге поля ввода, итх хендлы определяются. А вот хэндлы
А>кнопок и т.д. не определяются.
А>В чем дело? Причем, это во многих приложениях.

GetDlgItem ,помоему, и не должен работать. Откуда ты control identifier знаешь в чужой программе?
А кнопку можно найти по заголовку, примерно так:

HWND GetButtonHandle(HWND DlgWnd,LPCSTR ButtonText)
{
    HWND tmpWnd= GetWindow(DlgWnd,GW_CHILD);
    char Caption[30];
    while(tmpWnd)
    {
        GetWindowText(tmpWnd,Caption,30);
        if(strstr(ButtonText,Caption))
            break;
        tmpWnd= GetWindow(tmpWnd,GW_HWNDNEXT);
    }
    return tmpWnd;
}

Если на диалоге есть вложенные контролы то нужно будет рекурсивно искать.

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

AM>GetDlgItem ,помоему, и не должен работать. Откуда ты control identifier знаешь в чужой программе?

Предположим, что я знаю хендл, но дело не в этом.
Я перебираю все элементы диалога, примерно так как ты искал хендл кнопки.
По идее должны возвращаться хэндлы всех элементов, но возвращаются только два. У обоих класс EDTBX.

Вообще задача в том, чтобы управлять диалого Excel-я из другого, моего, диалога.
Я уже научился нажимать кнопки, но т.к. не могу получить хэндл, то нажимать кнопку приходится
по средством посылки WM_LBUTTONDOWN и WM_LBUTTONUP.

Все, казалось бы, хорошо. Но я не могу редактировать edit-ы.

Если интересно можешь сам проверить.
Я из своей программы открываю диалоговое окно Excel-я

PostMessage(hExcel,WM_COMMAND,32,0);

Хендл Excel-я нашли перебором всех окон и проверкой их заголовков на наличие Microsoft Excel.
Потом открываю диалоговое окно.
Потом ищу хэндл диалогового окна точно такще. причем начинаю поиск с GetTopWindow(NULL).
Если начинать поиск среди дочерних окон Excel, т.е. GetTopWindow(hExcel), то ничего не найдем.

Так, ну а дальше начинается самое интересное. Просматриваем все элементы диалога.
У еня находит только два окна редактирования. Остальных елементов как будто в этом окне нет.

Вообщем я в тупике.

Посмотрел я это диалог.Мне кажется, что проблемма в том что, этот диалог не совсем обычный.
Класс у него -"bosa_sdm_XL9". и детей и него всего два, оба -"EDTBX". Можешь сам через Spy++ посмотреть.
Обычные диалоги как правило имеют класс "#32770" и с ними довольно легко работать. A этот урод скорее всего какое нибудь порождение COM-а. Обычные методы тут не подходят. Попробуй добраться до него через COM.

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

AM>Посмотрел я это диалог.Мне кажется, что проблемма в том что, этот диалог не совсем обычный.
AM>Класс у него -"bosa_sdm_XL9". и детей и него всего два, оба -"EDTBX". Можешь сам через Spy++ посмотреть.
AM>Обычные диалоги как правило имеют класс "#32770" и с ними довольно легко работать. A этот урод скорее всего какое нибудь порождение COM-а. Обычные методы тут не подходят. Попробуй добраться до него через COM.

Хм, боялся я этих страшных слов
Честно говоря нигогда не работал с COM. Может какой примерчик на Win32 API
если возможно?

Честно говоря, не доконца понял в чем ваш вопрос, но возможно следующая цитата из Рихтера про ваш случай.

NOTE
--------------------------------------------------------------------------------
You can send window messages across process boundaries to interact with built-in controls (such as button, edit, static, combo box, list box, and so on), but you can't do so with the new common controls. For example, you can send a list box control created by a thread in another process an LB_GETTEXT message where the LPARAM parameter points to a string buffer in the sending process. This works because Microsoft checks specifically to see whether an LB_GETTEXT message is being sent, and if so, the operating system internally creates memory-mapped files and copies the string data across process boundaries.

Why did Microsoft decide to do this for the built-in controls and not for the new common controls? The answer is portability. In 16-bit Windows, in which all applications run in a single address space, one application could send an LB_GETTEXT message to a window created by another application. To port these 16-bit applications to Win32 easily, Microsoft went to the extra effort of making sure that this still works. However, the new common controls do not exist in 16-bit Windows and therefore there was no porting issue involved, so Microsoft chose not to do the additional work for the common controls.

=================================================================================
В кратце смысл в том, что старые элементы управления работали через границы процессов благодаря поддержке в системе. Для новых такая поддержка отсутствует.