Ну т.е. есть файл скажем test.tif и лежит пусть в App.Path
Надо
1) Распечатать его на выбранный принтер (прога знает)
2) Сразу же удалить (ну не нужен он мне по логике вопроса!)

Код (тестовый, иллюстрирующий суть полностью в аттаче):


В итоге файл удаляется раньше чем печатается и первая строка не работает.
Если DeleteFile убрать, то все работает.

Задача без решения?

Задержку - не хочу. Во первых она очевидно разная для 1 страницы и для 10 страниц.
Во вторых то-то и ценно что ShellExecute не тормозит прогу, а скидывает задание "системе".

Shocker.Proя обычно грохаю временные файлы при выходе из проги,...(на случай, если вдруг выход завершился аварийно) Думал об этом. Метод "временных файлов" я местами применяю, контроль при входе/выходе да, делаю, но удаляю штатно обычно когда наступает "понимание что файл больше не нужен". Но во-первых много мусора в temp (вдруг юзер прогу долго не перегружает, а объемы большие), а во вторых у меня в этом компоненте всегда
Shocker.Proслучай, если вдруг выход завершился аварийно)
Я конечно неграмотная темнота, но всегда закрываю его так из другого компонента(меня устраивает):
Посему остается если только:
Shocker.Proа также при входе в нее
Ну не знаю хорошо ли это будет.

А вообще суть в моем случае в чем.
Прога генерирует файлы TIFF.
В зависимости от настроек файл сохраняется в TIFF или PDF (типа "навсегда").
Но исх. файл всегда в TIFF.

1. TIFF
1) По появлению файла *.tif
2) Обрабатываем то чего с ним связано, например распечатываем
3) этот tiff остается лежать где и образовался

2. PDF
1) По появлению файла name.tif
2) Конвертируем path\name.tif в path\name.pdf
3) Обрабатываем то чего с ним связано, например распечатываем , при этом может использоваться name.tif из пункта (1)
4) по окончании обработки удаляем name.tif, а name.pdf остается лежать

Естественно я могу в пункте (3) делать printto(pdf) вместо printto(tif), но это чревато.
printto(pdf) обычно исполняется Acrobat Reader, но там есть проблема:
незакрытие окна Acrobat Reader после печати. Будучи исполненной из под CURRENT_USER это приведет к выводу и неубиранию окна ридера, а будучи исполненной из-под System (в режиме as Service NT), это приведет к полному стопору/ступору.
Решение как бы есть
http://www.biopdf.com/acrowrap/close_adobe_reader.php
но объяснять это user-у долго и не всегда эффективно.

Т.е. я к тому, что на печать правильнее всегда посылать tiff, тем более он итак уже всегда существует (на момент исполнения).

Хорошим вопросом будет такой:
Как сделать:
удаляю штатно ...когда наступает "понимание что файл больше не нужен".

ZVIЧем не устраивает сгененерировать BAT-файл, в котором выполнить printto, затем удаление TIF,...и запускать BAT-файл из кода Shell-ом?
1) Я не уверен, что я смогу задать параметр для printto если bat-file
CStr(Chr(34) & the_printer & Chr(34)) -произвольный!!!, а не default принтер
2) А будет ведь тоже самое скорее всего, TIFF удалится раньше, это ничего не меняет по сути

ZVIдавал ссылку на files.zip , в котром есть отдельная утилита printto.exe.
Ну...если с той утилитой, то требуемый фокус работает. Утилита ждет конца печати. Тест во вложении.
Не уверен, что я хочу использовать в приложении "ту утилиту" (а формально и права то не имею -там копирайт)...
Да и плюс -таки тормоз на время печати.
Вопрос чего она делает и как отсекает "процесс печати".
Как я упомянал, она как-то завязана на .net

ZVIВ принципе, можно после запуска ShellExecute 0, "printto", ... по таймеру, например, раз в полсекунды, контролировать появление и исчезновение печатаемого документа в очереди печати заданного принтера.По исчезновению из очереди удалять файл документа..
например раз в полсекунды можно и НЕДО-контролировать. В предыдущем тике ЕЩЕ нет, в последующем - УЖЕ нет.
ZVIЧтобы не иметь проблем с дубликатами печатаемых документов лучше их имена делать уникальными...
При генерации имен файлов программа контролирует уникальность имен.
Хотя есть возможность осуществлять печать одного и того же файла на более чем один принтер (уникальность имен принтеров в списке я контролирую в настройках).
ZVIПонадобятся API-функции: OpenPrinter, ClosePrinter, EnumJobs, lstrcpy и проч.
Не слишком ли большой огород для маленькой третьестепенной фичи?

И потом, если делать всякие "контролирования", то надо выносить "очередь заданий на печать (в программе!)" в отдельный "процесс" (делать "буфер"), т.е. напр. сохранять "чего печатать" в таблице БД, и разбираться с этим "отдельным таймером" например. Я так делаю с аналогичной ф-цией "отправки файла по e-mail".
Я же сейчас с печатью поступаю по принципу "Пихнул основным обработчиком в ShellExecute и забыл", это не тормозит основной обработчик.
В принципе вместо всех API и всего огорода утилиты printto.exe достаточно (можно ее и hex-ом "доработать", не съедят). Но естественно запускать ее именно "отдельным таймером".
Это ВАРИАНТ #1 но конечно требует дописывания кучи рутины.

ВАРИАНТ #2 следовать совету Shocker.Pro, копировать исх. TIFF в temp с приставкой printto_ name.tif, его и печатать через ShellExecute. Это точно не испортит и не нарушит логику программы.
Остается вопрос "ВЫВОЗ МУСОРА". Ну, удалять мусор при старте компонента (а по хорошему еще при удалении проги).

Есть еще конечно ВАРИАНТ #3 -научиться БЕЗОБИДНО печатать pdf-ы (Reader это безобидно по дефолту не делает), но копания в сторону например печати из GhostScript-а (его я в проге итак уже использую) к успеху не привели -муторно.

Еще правда
ВАРИАНТ #4 использование printto.exe непосредственно из основного обработчика (с ожиданием). Но "ожидание" в основном обработчике меня смущает, он не должен "ощутимо отвлекаться".

Т.е. все-таки больше склоняюсь к вариант #2, в меньшей степени к вариант #4.

AntonariyВариант 5: использовать объект Printer. ...Прочитать tif как картинку в IPictureDisp и сделать Printer.PaintPicture.
У-у-у...
Графическая (пере)(об)работка через GDI/GDI+ и печать средствами VB,
это при том что в моем распоряжении изначально корректный(хороший) TIFF файл
и аж 2 инструмента для его печати в одну строчку (да еще и на заданный(!) принтер).

Antonariyаж 2 инструмента для его печати в одну строчку И оба хромают, моля о костылях.
И чем же они хромают? Кроме моего субъективного желания избавиться от файла "как только так сразу"?
printto.exe кстати даже и не хромает.
Не говоря о том, что то что вы предлагаете тоже требует "времени ожидания" (за счет времени обработчика) на реализацию GDI-преобразования + VB-печати.
По сути это эквивалентно "printto.exe", разве что файл удаляете чуть может раньше (что не принципиально), но на "время ожидания" это вряд ли повлияет.
>полиграфическое качество
ну до полиграфии там по определению далеко. Речь идет о факсах 204x196 либо 204x98.

Antonariyprintto.exe кстати даже и не хромает.Таскать с собой лишний экзешник в вашем случае лучше, чем все в одном?
Если я решился таскать ghostscript 10MB, то таскать копеечный 10KB "printto.exe" погоды не сделает.
И я часто предпочитаю использовать чужой exe (как правило злоупотребляю системными) через shell, нежели иметь "все в одном". "Все в одном" означает 10 доп. API-модулей засунутые "в одно", и еще с риском (если где-то что-то не учел случайно) завалить всю прогу.
Хотя именно из-за нежелания таскать я и отказался от "printto.exe" в пользу ShellExecute в свое время.
Плюс там стоит Копирайт как я упомянул. Забить теги через hex конечно не проблема, но если вы посмотрите в свойства, то там еще есть цифровая подпись и я не уверен, что ее можно захексить с сохранением работоспособности файла. На законность вышеуказанного мне честно говоря на...но все же:во всяком случае бухать ориг. файл с незатертыми копирайтами и подписями в свой пакет я бы не стал.
AntonariyЧихать на время.
Нет не чихать. Код выполняется из ОБРАБОТЧИКА СОБЫТИЙ, кот. работает по таймеру и реагирует на разные события, и пока прога чихает/курит/ждет/отвлекается/висит/тупит, таймер выключен и мониторинга процессов в real time не происходит. И хорошо если прога все обработает корректно и в правильной последовательности по выходу из ступора, а вдруг что-то не учел и время критично.

Хотя я сам себе противоречу.
С одной стороны хочу проскочить печать "без остановки"
а с другой стороны хочу "дождаться, когда можно будет удалить файл".

В итоге я все же остановился на варианте 2:
копировать исх. TIFF в temp с приставкой printto_name.tif, его и печатать через ShellExecute. Это точно не испортит и не нарушит логику программы.
Остается вопрос "ВЫВОЗ МУСОРА". Ну, удалять мусор при старте компонента (а по хорошему еще при удалении проги).

По поводу "ВЫВОЗ МУСОРА".
Сделал так:
Код вставил:
1) при старте ОБРАБОТЧИКА
2) при убивании процесса ОБРАБОТЧИКА (как я писал он сам никогда не завершается нормально) в компоненты кот. убивают
3) в команду выполняемую при деинсталляции проги
Здесь сразу вопрос:
не подведет ли этот код
1) от XP до Win7
2) на x64
(не проверял)

Раньше я бы использовал иную конструкцию:
Но она имеет очевидный подвох:
Если по каким-то причинам какой-то файл не удалился(что НЕ критично),
то код зациклится (что КРИТИЧНО).
Изобретать еще один паравоз марки DEL с возможностью использования маски * и игнорирования, если файл вдруг не удалился, считаю нецелесообразным.

ZVIGetEnvarVar("Temp")
Ну, если интересно,
Этому я как раз более менее доверяю.
Юзер может и без батника пойти в "Мой компьютер" и наменять, при этом должен отдавать себе отчет, не так ли?
Когда я спрашивал о надежности на win7 или x64, я имел ввиду
1) cmd
2) del
3) Ну и еще синтаксис строчки кода на всякий случай