private:
FolderWatcher _folderWatcher;
};
Теперь, когда мы знаем, как иметь дело с уведомлением, давайте взглянем на их источники, События изменяющие файлы. Объект события создан файловой системой в ответ на FindFirstChangeNotification. Дескриптор этого события возвращен из вызова. Мы запоминаем этот дескриптор и используем его позже, чтобы или осуществить восстанавление или отказаться от нашего интереса к дальнейшим уведомлениям. Обратите внимание, что мы можем устанавливать наблююдение рекурсивно, то есть, наблюдать данную папку и все ее подпапки и подподпапки. Мы можем также выражать интерес к специфическим изменениям, передавая поразрядное ИЛИ для любой комбинации следующих флажков:
• FILE_NOTIFY_CHANGE_FILE_NAME (переименование, создание или удаление файла)
• FILE_NOTIFY_CHANGE_DIR_NAME (создание или удаление каталога (папки))
• FILE_NOTIFY_CHANGE_ATTRIBUTES
• FILE_NOTIFY_CHANGE_SIZE
• FILE_NOTIFY_CHANGE_LAST_WRITE (сохранение файла)
• FILE_NOTIFY_CHANGE_SECURITY
Для удобства мы определили несколько подклассов от FileChangeEvent, которые соответствуют к некоторым полезным комбинациям этих флажков. Один из них — FolderChangeEvent, который мы использовали в нашем FolderWatcher.
class FileChangeEvent {
public:
FileChangeEvent(char const *folder, BOOL recursive, DWORD notifyFlags) {
_handle = FindFirstChangeNotification(folder, recursive, notifyFlags);
if (INVALID_HANDLE_VALUE == _handle) throw WinException("Cannot create change notification handle");
}
~FileChangeEvent() {
if (INVALID_HANDLE_VALUE != _handle) FindCloseChangeNotification(_handle);
}
operator HANDLE() const { return _handle; }
BOOL ContinueNotification() {
return FindNextChangeNotification(_handle);
}
private:
HANDLE _handle;
};
class FolderChangeEvent : public FileChangeEvent {
public:
FolderChangeEvent(char const* folder) : FileChangeEvent(folder, FALSE, FILE_NOTIFY_CHANGE_FILE_NAME) {}
};
class TreeChangeEvent : public FileChangeEvent {
public:
TreeChangeEvent(char const * root) : FileChangeEvent (root, TRUE, FILE_NOTIFY_CHANGE_FILE_NAME | FILE_NOTIFY_CHANGE_DIR_NAME) {}
};
Должно быть теперь просто обобщить этот пример, чтобы сделать некоторую действительно полезную работу в ваших программах. Не забудьте посмотреть API, который мы используем в этих обучающих программах, в интерактивной справке, которая идет с вашим компилятором.
Далее: Программирование OLE и использование COM без MFC.
Оболочка из классов для COM
Использование оболочки Windows совместно с COM
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Программировать с использованием COM настолько трудно, что Вы не должны даже пробовать это без MFC. Правильно или неправильно? Абсолютная чушь! Рекламируемые OLE и его преемник COM имеют элегантность гиппопотама, занимающегося фигурным катанием. Но размещение MFC на вершине COM подобно одеванию гиппопотама в клоунский костюм еще больших размеров.
Загрузите исходник примера, TreeSizer (zip архив 12 кб, любезность Laszlo Radanyi), в котором вычисляется суммарный размер всех файлов в некотором каталоге и всех его подкаталогах. Он, для просмотра каталогов, использует окно просмотра оболочки Windows.
Итак, что делать программисту, когда он столкнется с потребностью использовать возможности оболочки Windows, которые являются доступными только через интерфейсы COM? Читайте …
Для начала, всякий раз, когда Вы планируете использовать COM, Вы должны сообщить системе, чтобы она инициализировала COM подсистему. Точно так же всякий раз, когда вы заканчиваете работу, Вы должны сообщить системе, чтобы она выгрузила COM. Самая простой способ это сделать заключается в определении объекта, конструктор которого инициализирует COM, а деструктор выгрожает ее. Самое лучшее место для внедрения данного механизма — это объект Controller (см. Windows программу Generic), подобный этому.
class Controller {
public:
Controller(HWND hwnd, CREATESTRUCT * pCreate);
~Controller();
// … private:
UseCom _comUser; // i'm a com user
Model _model;
View _view;
HINSTANCE _hInst;
};
Этот способ гарантируют, что COM подсистема будет проинициализирована прежде, чем к ней будут сделаны любые обращения и что она будет освобождена после того, как программа осуществит свои разрушения (то есть, после того, как "Вид" и "Модель" будут разрушены).
Класс UseCom очень прост.
class UseCom {
public:
UseCom() {
HRESULT err = CoInitialize(0);
if (err != S_OK) throw "Couldn't initialize COM";
}
~UseCom() {
CoUninitialize();
}
};
Пока не было слишком трудно, не так ли? Дело в том, что мы не коснулись главной мерзости COM программирования — подсчета ссылок. Вам должно быть известно, что каждый раз, когда что Вы получаете интерфейс, его счетчик ссылок увеличивается. И Вам необходимо явно уменьшать его. И это становится более чем ужастным тогда, когда Вы начинаете запрашивать интерфейсы, копировать их, передавать другим и т.д. Но ловите момент: мы знаем, как управляться с такими проблемами! Это называется управлением ресурсами. Мы никогда не должны касаться интерфейсов COM без инкапсуляции их в интеллектуальных указателях на интерфейсы. Ниже показано, как это работает.
Примечание. В настоящий момент данная тема достаточно широко рассмотрена в литературе, переведенной на русский язык. В частности, можно отметить книги:
Джефф Элджер. "C++: библиотека программиста";
Скотт Мейерс. "Эффективное программирование на С++".
А.Л.
template <class T>
class SIfacePtr {
public:
~SIfacePtr() {
Free ();
}
T * operator->() { return _p; }
T const* operator->() const { return _p; }
operator T const * () const { return _p; }
T const& GetAccess () const { return *_p; }
protected: SIfacePtr () : _p (0) {}
void Free () {
if (_p != 0) _p->Release();
_p = 0;
}
T * _p;
private:
SIfacePtr(SIfacePtr const& p) {}
void operator=(SIfacePtr const& p) {}
};
Не волнуйте, что этот класс выглядит непригодным (потому что имеет защищенный конструктор). Мы никогда не будем использовать его непосредственно. Мы наследуем от него. Между прочим, это удобный прием: создайте класс с защищенным пустым конструктором, и осуществите наследование от него. Все наследующие классы должны обеспечивать их внутреннюю реализацию своими открытыми конструкторами. Поскольку Вы можете иметь различные классы, наследующие от SIfacePtr, они будут отличаться по способу получения, по их конструкторам, рассматриваемым интерфейсам.
Закрытые фиктивный копирующий конструктор и оператор "=" не всегда необходимы, но они сохранят Вам время, потраченное на отладку, если по ошибке вы передадите интеллектуальный интерфейс по значению вместо передачи по ссылке. Это больше невозможно. Вы можете освободить один и тот же интерфейс, дважды и это будет круто отражаться на подсчете ссылок COM. Верьте мне, у меня это случалось. Как это часто бывает, компилятор откажется передавать по значению объект, который имеет закрытую копию конструктора. Он также выдаст ошибку, когда Вы пробуете присвоить объект, который имеет закрытый оператор присваивания.
Для завершения этого короткого введения, позвольте мне представить еще одну вариацию на тему интеллектуальных указателей. Оболочки API часто распределяет память, используя свои собственные специальные программы распределения. Это не было бы настолько плохо, если бы не предположение, что они ожидают от вас освобождения памяти с использованием той же самой программы распределения. Так, всякий раз, когда оболочка вручает нам такой сомнительный пакет, мы обворачиваем его в специальный интеллектуальный указатель.
template <class T> class
SShellPtr {
public:
~SShellPtr() {
Free();
_malloc->Release();
}
T* weak operator->() { return _p; }
T const* operator->() const { return _p; }
operator T const* () const { return _p; }
T const& GetAccess () const { return *_p; }
protected:
SShellPtr() : _p(0) {
// Obtain malloc here, rather than
// in the destructor.
// Destructor must be fail-proof.
// Revisit: Would static IMalloc * _shellMalloc work?
if (SHGetMalloc(&_malloc) == E_FAIL) throw Exception "Couldn't obtain Shell Malloc";
}
void Free() {
if (_p != 0) _malloc->Free(_p);
_p = 0;
}
T * _p;
IMalloc* _malloc;
private:
SShellPtr(SShellPtr const& p) {}
void operator=(SShellPtr const & p) {}
};
Обратите внимание на использование ранее показанного приема: класс SShellPtr непосредственно не пригоден для использования. Вы должны наследовать от него подкласс и реализовать в нем соответствующий конструктор.
