Мобильная версия форумов
Открыть
 −7°C
завтра: −11°C
Погода в Перми
−7°C
вечером−7°C
ночью−10°C
завтра−11°C
Подробно
 65,51
−0.0252
Курс USD ЦБ РФна 23 февраля
65,5149
−0.0252
 74,33
+0.0369
Курс EUR ЦБ РФна 23 февраля
74,3332
+0.0369
  • Анонимный пользователь
    Требуется генерить doc-файлы разного содержания в зависимости от шаблонов, хранящихся отдельно в формате dot.
    Это предварительная структура системы - может быть кто-нибудь посоветует более эффективный способ реализации. Вообще, большая часть контента генерится на основе данных БД (подобие генератора отчетов). Соответственно, sql-запросы для получения тех или иных данных хранятся в подклассах отдельного класса и вызываются в зависимости от выбранного темплэйта. Можно, в принципе, и остальное (статическое) содержимое документа хранить там же - его не так много. Просто вариант с .dot-ами лучше тем, что позволяет при крайней необходимости редактировать файлы шаблонов. Использую Visual C++.

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

    Есть мысли?

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

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

  • guru

    Сообщений: 3019

    Архитектура приложения (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;
    }

  • activist

    Сообщений: 341

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

    Блин, родился...

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

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

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

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

  • guru

    Сообщений: 3019

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

  • рыжий котэ

    Сообщений: 12083

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

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

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

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

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

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

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

    Спасибо.

Записей на странице:

Перейти в форум

Модератор: