cmail.dll Архивирование #300558

Почему когда пишу так,то архивируется криво?Т.е.архив повреждён или имеет не известный формат... Зато когда оформляю в виде отдельной функции,то работает нормально.. Код во внешнем отчёте,форма которого открывается при записи документа.

Почему когда пишу так,то архивируется криво?Т.е.архив повреждён или имеет не известный формат... Зато когда оформляю в виде отдельной функции,то работает нормально.. Код во внешнем отчёте,форма которого открывается при записи документа.

а кто пишет "архив поврежден"?

вот это тоже лишнее: СокрЛП("111.ZIP"), т.е. в данном случае урезать пробелы смысла нет :)

создаётся архив,но когда его вручную пытаюсь распаковать,выдаёт такое. А если код поместить в модуль документа(что мне удобнее),то оба способа криво создают архив..но в окне сообщения пишет: Архивирование 1

ну да..это-то лишнее..но думаю не из-за этого же так)

не из-за этого :) значит так: если объект Addin.Mail уже создан, то создавать по новой - не нужно, вынос в отдельную функцию я б счел более верным. теперь о ручном открытии: применяется нестандартное немного архивирование, т.е. это вариант алгоритма, похожий на который юзается в архиваторе zip, но не такой. такие файлы можно открыть только этой же компонентой (по крайней мере у меня ни rar, ни zip, ни 7zip не справлялись)

+6 если при архивировании идут ошибки, то они в виде модального окна выскакивают (на инглише написан код ошибки и т.п.), если такого нет - то и ошибок нет.

у меня очень хорошо вручную распаковывается,если использовать метод в виде отдельной функции,причём ток во внешнем отчёте(переделанный example.ert).

я не вполне верно выразился: архив может не распаковаться вручную - так корректнее. и еще: если архив многотомный (т.е. разбит на части) - тогда вряд ли он вообще ч.-л. распакуется кроме как "родной" dll-кой. если не критично - так и юзай, как в примере, там точно все рабочее :) P.S. немного мимо сабжа, но: а зачем каждый документ так вот отправлять при записи, может стоит отправлять к.-л. обработкой за какой-то промежуток времени? имхо так лучше будет. могу подсказать вариант более-менее беспроблемного обмена

По условию при создании документа нужно все данные поместить в файл,заархивировать его и тут же отправить по мылу

+10 На другом конце сидит оператор и принимает эти файлы)

оператор принимает вручную? а потом голосом перезванивает и говорит, принял или нет? :) так не пойдет. лучше так: 1. при формировании (раз уж так нужна имитация онлайна, хотя имхо это перебор) отсылаем по почте или выкладываем на ftp (компонента dialmail это умеет) 2. через определенный интервал проверяется автоматом(!) почта (или мониторится каталог на ftp - это уже здесь обсуждалось и если есть базовые знания тех же делфей - можно сваять сервис, который будет мониторить каталог на изменения) 3. при появлении новых писем (файлов на ftp) письмо принимается и обрабатывается и в случае успеха (и только!) отсылается (выкладывается на ftp) "квитанция" о приеме (пустое письмо с темой типа "Confirm#<намер пакета>") 4. при следующей отправке автоматом принимаем квитанции и обрабатываем их. что нужно еще: общий реквизит (или если это один вид документов, то реквизит документа) типа "число", тумблер, у которого три положения: 0 - не отправлять, 1 - готов к отправке, 2 - отправлен, одидается подтверждение. этот реквизит выставлять единицей, если док меняли (записывали), двойкой после успешной отправки, нулем - при получении "квитанции" документы лучше конечно сливать по нескольку штук в "пакеты", пакеты нумеровать (в теме писать аналогичное с квитанцией, т.е. "Package#<номер пакета>") пакеты нумеровать проще исходя из даты-времени или даты и значения недокументированной функции _GetPerformanceCounter (статистически повторений не будет) ну примерно так.