Нужен хотя бы самый простой пример работы с компонентом WordDocument для Builder C++. Или с другими компонентами из этой линейки, позволяющие передвать данные из приложения в MS Word с сохранением форматирования текста. DELPHI не предлагать, для них примеров полно.
а) vs означает versus, что означает "или". Надо Builder with Word б)сам поменять не можешь что ли например WordApplication1.connect на WordApplication1->connect()?. как то так, билдера под рукой нет, могу и ошибиться. tvariant filename; filename=tvariant(путь к шаблону) WordApplication1->connect(); WordApplication1->documents->add(&filename,EmptyParam); WordDocument1->ConnectTo(WordApplication1->ActiveDocument); WordDocument1->Selection->TypeText(TVariant("блабалабалабла"));
TVariant filename; Немного не так ты мне подсказал, вот что получилось: filename=TVariant("c:\\normal.dot"); WordApplication->Application->ShowMe(); WordApplication->Connect(); WordApplication->Documents->Add(&filename,EmptyParam); WordDocument->ConnectTo(WordApplication->ActiveDocument); WordApplication->Selection->TypeText(TVariant("Ну вот я и в вордЕ!")); WordApplication->ScreenUpdating = True; WordApplication->Disconnect();
Я не люблю использовать стандартные компоненты для офиса из билдера. По-моему лучше пользоваться сервером автотоматизации. И все операции производить через OLE. Если будет интересно скину как.... Тем более, что когда делаешь через OLE программа не привязывается к конкретной версии Ворда(97, 2000 или ХР), а работает на всех подряд... (правда под Вин 3.11 не проверяла)
на самом деле это то что ты написала называется позднее связывание, потому что и в случае раннего связывания word будет являтся сервером автоматизации, и операции будут призводится через OLE . Ранее связывание имеет свои серьезные преимущества типа проверки на этапе компиляции. Проблема разных версий ворда существует, но если не используются специфичные для версий вызовы, то они решаются.
не знаю как оно правильно обзывается, но мне почему-то всетаки удобнее работать с Вордом без использования компонент. Честно признаться даже не знаю почему: попробовала сначала через компоненты и что-то не пошло, кто-то мне подсказал обратиться к ворду через OLE без использования стандартных компонентов. Я лично, это называю "на прямую".... Вот тогда вопрос: ты хорошо знаком с этим "поздним связыванием"? Я с вордом более менее разобралась, теперь хотелось бы Access подучить... или ссылочку где почитать можно, если знаешь, пожалуйста, скинь...
C Accessом таким образом работать нет необходимости. для этого надо использовать универсальные средства доступа к данным-ADO или DAO. Что конкретно то надо?
У меня тута две большие базы одна на Access(850 Mb), а другая на MS SQL(3,5 Гб) Вот я и вибираю, но тоже сейчас больше склоняюсь к ADO. Вот тока вопрос: будут ли тормоза больше или меньше при использовании ADO (еще ни разу с ним не работала) - в таблице где 1миллион записей при фильтровании???
позднее связывание работает через интерфейс IDispatch. этот интерфес был специально создан для того, чтобы поддержать использование СОМ (кстати OLE, ПиВО ;-) - Привязывание и Внедрение Объектов, здесь ни причем) скриптовыми языками и Visual Basic-ом. в принципе, каждый выбирает как ему удобнее, но замечу, время, затраченное при вызове метода через диспинтерфейс будет больше, чем при вызове метода напрямую (в случае внутрипроцессного сервера затраты практически равны затратам на вызов виртуальной функции), так как происходит распаковка и упаковка аргументов, а также поиск и переход на вызов нужного метода. так что если Вам в цикле нужно много раз метод СОМ-объекта, то стоит протестировать время выполнения вашего метода. способ вызова метода СОМ объекта становится менее важен, если используется DCOM и при обрашении к внепроцессному серверу. в случае СОМ+, там и так все работает через контекст. на данный момент практически все СОМ серверы предоставляют двойственные интерфейсы (dual), так что можно работать и так и так. плюсы раннего связывания: проверка типов на этапе компиляции, скорость и еще один, неявный - полазив по библиотеке типов, можно больше узнать об объектах, интерфейсах и константах. при раннее и позднее связывания могут отличаться измением способа вызова методов и передачи аргументов. теперь по поводу доступа к SQL Server (на примере 2000) существует несколько API: ADO - объектная надстройка над OLEDB, достаточный уровень управления разработкой, поддерживается боьшинство особенностей сервера, XML, OLAP URL (новое) - потоки через OLEDB, низкий контроль за разработкой, ограниченная поддержка сервера, XML, применяется в HTML&ASP OLEDB - есть все. ODBC - все кроме олапа и хмл RDO в отличии от АДО, объектная надстройка над ODBC, соответсвенно нет олапа и хмл DAO, DB-Library, E-SQL - это устаревшие библиотеки, они были работоспособными для SQL 6.5 так что выбор невелик. кстати, Access, можно прилинковать к SQL Server как внешний сервер м работать с ним как с SQL ;-). были случаи, когда DBF базы 1С прилинковывались к SQL Server и все работало на ура ;-) про количество записей. про фильтрацию (применительно к SQL Server это слово мне нравится, лучше - запрос) приблизительно!!! можно так сказать: есть результат запроса, а есть серверный курсор результат запроса, как правило, передается на клиента, курсор - остается на сервере и на клиенте записи появляются по мере обращения к серверу за необходимыми записями. я лично не использую серверные курсоры. в случае с миллионом записей несложно выполнить 2 подсчета 1. предположим одна запись 32 байта - это где-то 30 Мб памяти + время на передачу данных по сети, выделение памяти и т.д. слишком круто. 2. в одну секунду я просматриваю 5 !!! записей, чтобы просмотреть все мне надо затратить где-то 60 часов. тоже не совсем-то. отсюда вывод - что-то у Вас неправильно.
я имею ввиду, что запрос, возвращаюший один миллион записей, не то, чтобы неправильный, он просто бессмысленный. ПС. лучше все-таки на Вы обращаться, Вы меня не знаете, я Вас тоже.