Стоит заметить, что интерфейс IHTMLEventObj доступен только на время обработки конкретного события. При этом не все свойства в контексте определенного события имеют смысл. Например, значения возвращаемые функциями get_fromElement и get_toElement доступны только при обработке событий мыши onmouseover и onmouseout.
В следующем примере в обработчике обределяется нажатая клавиша и выводится соответствующее диалоговое окно. Если была нажата клавиша Enter, то дальнейшая обработка отменяется.
void CMyHtmlView::OnKeyDown(DISPID id, VARIANT* pVarResult) {
HRESULT hr;
LPDISPATCH pDispatch = GetHtmlDocument();
if (pDispatch != NULL) {
IHTMLDocument2* pHtmlDoc;
hr = pDispatch->;
QueryInterface(__uuidof( IHTMLDocument2), (void**)&pHtmlDoc);
IHTMLWindow2* pWindow;
IHTMLEventObj* pEvent;
hr = pHtmlDoc->get_parentWindow(&pWindow);
ASSERT(SUCCEEDED(hr));
hr = pWindow->get_event(&pEvent);
ASSERT(SUCCEEDED(hr));
// Определяем нажатую клавишу
long nKey;
hr = pEvent->get_keyCode(&nKey);
ASSERT(SUCCEEDED(hr));
// Если Enter не хотим обрабатывать дальше
if (nKey == VK_RETURN) {
V_VT(pVarResult) = VT_BOOL;
V_BOOL(pVarResult) = FALSE;
}
pDispatch->Release();
pWindow->Release();
pEvent->Release();
pHtmlDoc->Release();
CString sMes;
sMes.Format("CEventView::OnKeyDown(DISPID = %d)nKeyCode: %d", id, nKey);
AfxMessageBox(sMes);
}
}
В заключение
Чтобы собрать воедино все фрагменты приведу небольшой пример (event.zip). Запустите его и выберите команду меню EventOnKeydown. Теперь понажимайте клавиши внутри страницы. И посмотрите, что из этого получится. В этом примере регистрируется только один обработчик, но я думаю дочитав эту статью вы без труда сможете реализовать любой другой.
В заключение хочется заметить, что в этой статье я затронул только один небольшой аспект использования элемента WebBrowser. Если Вас заинтересует данная тема, пишите, продолжим.
ВОПРОС – ОТВЕТ
Как получить список запущенных приложений?
Автор: Александр Федотов
Тестовое приложение Process Viewer – pview.zip (130 Kb)
Операционная система Windows знаменита своими окнами. Поэтому, когда заходит речь о приложениях, пользователи ассоциируют их с окнами, хотя с технической точки зрения правильнее было бы оперировать понятием процесса. В частности, под списком приложений пользователи часто подразумевают не список процессов, а список главных окон приложений, видимых на экране. В таком случае, задача перечисления приложений сводится к перечислению их главных окон.
Для перечисления всех окон верхнего уровня служит функция EnumWindows, однако, если мы просто вызовем эту функцию, то обнаружим, что она возвращает много больше окон, чем видно приложений на экране. Очевидно, мы должны игнорировать невидимые окна и окна, имеющие владельца (такие как диалоговые панели). Но даже и после этой фильтрации в списке будет несколько больше окон, чем отображает Task Manager.
Проведя несколько экспериментов с Windows NT Task Manager, удалось установить, что он игнорирует окна с пустым заголовком, и, как ни странно, окна с заголовком "Program Manager". Да-да, если вы создатите свое окно с таким заголовком, то оно не появится в списке приложений Task Manager. Обычно в системе есть только одно окно "Program Manager" – это то окно, на котором находится рабочий стол. Понятно, что пользователи не ассоциируют это окно с каким-либо приложением, для них оно является неотъемлемой частью компьютера, и поэтому Task Manager должен игнорировать это окно. Непонятно только, почему разработчики Task Manager решили определять это окно по его заголовку, а не по имени класса окна, которое есть "progman".
После того, как мы вставим все эти проверки, наш список уже ничем не будет отличаться от выводимого Task Manager. Ниже приведен код функцииEnumApplications, которая реализует перечисление приложений. Интерфейс функции построен в стиле функций-перечислителей в Win32 API: она принимает указатель на пользовательскую функцию, которую вызывает для каждого перечисляемого приложения.
typedef BOOL (CALLBACK * PFNENUMAPP)(
IN HWND hWnd, // идентификатор главного окна приложения
IN LPCTSTR pszName, // название приложения
IN HICON hIcon, // иконка приложения
IN LPARAM lParam // пользовательский параметр
);
typedef struct _ENUMAPPDATA {
LPARAM lParam;
PFNENUMAPP pfnEnumApp;
} ENUMAPPDATA, * PENUMAPPDATA;
static BOOL CALLBACK EnumWindowsCallback(IN HWND hWnd, IN LPARAM lParam) {
PENUMAPPDATA pEnumData = (PENUMAPPDATA)lParam;
_ASSERTE(_CrtIsValidPointer(pEnumData, sizeof(ENUMAPPDATA), 1));
if (!IsWindowVisible(hWnd) || GetWindow(hWnd, GW_OWNER) != NULL) return TRUE;
TCHAR szClassName[80];
GetClassName(hWnd, szClassName, 80);
if (lstrcmpi(szClassName, _T("Progman")) == 0) return TRUE;
// получаем заголовок окна
TCHAR szText[256];
DWORD cchText = GetWindowText(hWnd, szText, 256);
if (cchText == 0) return TRUE;
HICON hIcon = NULL;
// получаем иконку окна
if (SendMessageTimeout(hWnd, WM_GETICON, ICON_SMALL, 0,
SMTO_ABORTIFHUNG|SMTO_BLOCK, 1000, (DWORD_PTR *)&hIcon)) {
if (hIcon == NULL) {
if (!SendMessageTimeout(hWnd, WM_GETICON, ICON_BIG, 0,
SMTO_ABORTIFHUNG|SMTO_BLOCK, 1000, (DWORD_PTR *)&hIcon)) hIcon = NULL;
}
} else hIcon = NULL;
if (hIcon == NULL) hIcon = (HICON)GetClassLong(hWnd, GCL_HICONSM);
if (hIcon == NULL) hIcon = (HICON)GetClassLong(hWnd, GCL_HICON);
if (hIcon == NULL) hIcon = LoadIcon(NULL, IDI_APPLICATION);
// вызываем пользовательскую функцию
return pEnumData->pfnEnumApp(hWnd, szText, hIcon, pEnumData->lParam);
}
BOOL EnumApplications(IN PFNENUMAPP pfnEnumApp, IN LPARAM lParam) {
_ASSERTE(pfnEnumApp!= NULL);
ENUMAPPDATA EnumData;
EnumData.pfnEnumApp = pfnEnumApp;
EnumData.lParam = lParam;
return EnumWindows(EnumWindowsCallback, (LPARAM)&EnumData);
}
Как видно, функция EnumApplications чрезвычайно проста – она просто вызывает EnumWindows и вся основная работа по фильтрации ненужных окон ложится на вспомогательную функцию EnumWindowsCallback.
В функции EnumWindowsCallback мы сначала отсеиваем невидимые окна, и окна, имеющие владельца. Затем мы проверяем, не является ли данное окно окном рабочего стола. Здесь мы не уподобляемся разработчикам Windows NT Task Manager и используем имя класса окна для проверки. Наконец, мы отбрасываем окна с пустым заголовком.
После того, как мы определи, что данное окно представляет некоторое приложение, мы собираем информацию об окне, чтобы передать ее пользовательской функции. Сначала мы получаем заголовок окна с помощью хорошо известной функцииGetWindowText. Затем мы пытаемся получить иконку окна. Обратите внимание, мы используем функцию SendMessageTimeout с флагом SMTO_ABORTIFHUNG для посылки сообщения WM_GETICON. Это гарантирует, что наше приложение не зависнет, даже если приложение, которому принадлежит окно, перестало обрабатывать сообщения.
Когда все параметры определены, мы вызываем пользовательскую функцию. Пользовательская функция, в свою очередь, может распоряжаться этими данными по своему усмотрению. Например, в тестовом приложении Process Viewer, которое сопровождает эту статью, она добавляет очередной элемент в список приложений.
Cсылки1. Q175030 HOWTO: Enumerate Applications in Win32, Microsoft Knowledge Base.
ФОРУМ RSDN – ИЗБРАННОЕ
Тема: ООП и наследование
Вопрос: Есть базовый класс, из ЕГО конструктора вызывается метод ЭТОГО же (базового) класса.
Cbase::Cbase() {
someFunction();
}
void Cbase::someFunction() {
<SOME ACTION>
}
Так вот. Этот класс наследуют другие классы. НО! В их конструкторах нет вызова someFunction(), – КОТОРАЯ ВИРТУАЛЬНАЯ, и по логике должна переназначаться классами, которые наследуют Cbase
Но при объявлении Csomefrombase : public Cbase, при объявлении объекта вызывается someFunction() класса Cbase! Но нужно, чтобы вызывалась ТОЛЬКО Csomefrombase::someFunction()!
Кто-нибудь подскажет, как решить данную проблему?
Utandr
Предположим, всё работает по твоей логике. Угадай, что произойдёт вот в таком случае?
class A {
public:
A() { f(); }
virtual void f() {}
};
class B: public A {
public:
int *n;
B() {
n = new int[10];
}
};
class C: public B {
public:
virtual void f() {
for (int i=0; i<10; i++) n = 0;
}
};
IT
Из конструктора даже виртуальные методы вызываются в соостветствии со статическим (а не динамическим) типом класса. Т.е. при вызове метода 'foo()' из конструктора класса 'A' всегда вызывается метод 'A::foo()', независимо от того, переопределялся ли это метод в наследнике или нет. В этом есть смысл: в момент выполнения конструктора базового класса класс-наследник еще не сконструировался и попытки вызывать его методы ни к чему хорошему не приведут (см. пример от IT)
