Требуется генерить doc-файлы разного содержания в зависимости от шаблонов, хранящихся отдельно в формате dot.
Это предварительная структура системы - может быть кто-нибудь посоветует более эффективный способ реализации. Вообще, большая часть контента генерится на основе данных БД (подобие генератора отчетов). Соответственно, sql-запросы для получения тех или иных данных хранятся в подклассах отдельного класса и вызываются в зависимости от выбранного темплэйта. Можно, в принципе, и остальное (статическое) содержимое документа хранить там же - его не так много. Просто вариант с .dot-ами лучше тем, что позволяет при крайней необходимости редактировать файлы шаблонов. Использую Visual C++.

Каким образом (MFC) подойти к решению?
По сути, это Document/View, однако насколько глубоко следует зарываться в детали этого принципа?

Есть мысли?

MFC тут как зайцу реле поворота.
Рыть надо в сторону COM управления MSWord (OleAutomation). Очень хорошо документировано (см. MSDN), в инете масса примеров и на C++, и для Delphi, и для VBA.

Еще вопрос на эту тему.
Какова возможная роль Document/View в реализации данной задачи? Может ли она рельно упростить структуру проекта?

Архитектура приложения (Document/View) никакого отношения не имеет к работе с СОМ-объектами.
Ниже - пример работы с Вордом.

#import "MSO9.DLL"	rename("RGB", "MsoRGB")

#import "VBE6EXT.OLB"

#import "MSWORD9.OLB"	rename("ExitWindows", "WordExitWindows")\

			rename("FindText", "WordFindText")



int main(int argc, char* argv[]) {

	Word::_ApplicationPtr ptrWord;

	Word::_DocumentPtr ptrDoc;



	HRESULT hr;

	hr = CoInitialize(NULL);

	if (FAILED(hr)) return -1;



	hr = ptrWord.CreateInstance(__uuidof(Word::Application));

	if (FAILED(hr)) {

		CoUninitialize();

		return -1;

	}



	ptrWord->Visible = VARIANT_TRUE;



	ptrDoc = ptrWord->Documents->Add(&_variant_t("c:\\MyTemplate.dot"));

	ptrWord->Selection->TypeText("Hello, Word ;-)");

	ptrDoc->SaveAs(&_variant_t("c:\\MyDoc.doc"));

	ptrWord->Quit();



	CoUninitialize();

	return 0;

}

а на VBА нельзя?

На VBA нельзя, поскольку это модуль системы, реализованной с помощью Visual C++.

Что касается работы с файлами Office, большое спасибо за пример. В принципе, смысл прояснился.
Однако возник вопрос:
Где в системе можно найти путь к директории Office?
Использование
C:\Program Files\Microsoft Office\Office\MSO9.DLL

на мой взгляд, крайне несерьезно.
У меня вот, например, офис лежит на d:\soft\

Где это прописано? Может, в реестре где? Там, правда, при попытке поиска тако-о-ое вылазит...

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

В некоторых случаях, если использовать самые ранние библиотеки, то и на совместимость вверх рассчитывать не приходится.

Так, с генерацией/сохранением вордовских файлов понятно, всем большое спасибо. Все вполне логично, хоть и позапариваться есть где.

Вообще, больший приоритет в данной задаче имеет производительность (скорость генерирования/сохранения файлов), но в то же время и контент отчетов сравнительно простой.

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

Просто время для поиска оптимального решения, как ни странно, в данном случае имеется, поэтому хочется найти максимально подходящий вариант.

Кто что подскажет из опыта?

Спасибо.