Задача - печать файла (пусть будет картинка "C:\path\mypict.tif") на заданный принтер "MyPrinterName".

Решение #1. Метод "printto". Реализация:


Метод имеет недостатки. В реестре может не оказаться ключа
HKEY_CLASSES_ROOT\TIFImage.Document\shell\printto\command


И на 8-ке/8.1 в 99 случаев из 100 печать не сработает.

Но shimgvw.dll есть везде и всегда, поэтому правильнее
Print an image using ShellExecute (CSShellPrintImageWithShellExecute)

Решение #2. использовать shimgvw.dll в лоб :



Проблема. ret всегда больше 32, даже если печать не удалась.
А мне надо знать результат НАПЕЧАТАЛИ УСПЕШНО либо ОШИБКА. Как узнать?
Косвенно: делаю проверку на GDI-совместимость.
Но иконки (ico) например на GDI проходят, а на XP ImageView_PrintTo их не печатает. Т.е. такая проверка замороченная и не точная.
Пытался вызывать ImageView_PrintTo декларируя ее как обычную API -должна же она что-то возвращать - ничего не получается-не работает, только через rundll32.exe.
Т.е. printto не надежен в плане гарантии печати (но ошибку в случае не печати ShellExecute возвращает четко).
А здесь печатает четко (то что должен печатать), но не возвращает результат (где гарантия что в ф-цию не подсунут текстовуху переименованную в jpg).
Как выкручиваться?

Дмитрий77Можно ли как-то понять, что возвращает API
Засада, ничего она не возвращает.
После чтения этой статьи

СВЕДЕНИЯ: интерфейс программ Windows Rundll и Rundll32

удалось грамотно запустить ImageView_PrintTo вообще напрямую (без rundll32.exe и ShellExecute):




Работает (метод кстати универсальный для таких штук).
Но возвращает всегда 0 - даже если печать не состоялась.
Т.е. ничего не возвращает.

А как мне отследить УСПЕХ/ НЕ УСПЕХ печати?

ATM-TURBO 2,

ATM-TURBO 2,

ничего она умного не возвращает, и не может вернуть в принципе.
Потому что нет ошибки.

Даже если печатать через shimgvw.dll,ImageView_PrintTo заведомо невалидный файл, т.е.
pdf
txt
ico (в XP не печатает, в 8-ке печатает)
пустой bmp
пустышку неверного формата например txt переименованный в jpg, bmp и т.п.
то ОН ЕГО ВСЕ РАВНО "ПЕЧАТАЕТ" -это ясно из появления монитора принтера в трее, т.е. err как таковой просто нет

Проблема всплывает потом, не будучи отслеженной. Я использую виртуальный принтер (результат - образование файла tiff), который по окончании печати запускает некоторый EXE с параметром имя файла tiff, кот. есть результат печати.
(механизм запуска exe и сам принтер -чужие - хакнуты мной из другой проги, а вот этот exe -моего производства) - Дык вот, во всех проблемных случаях (pdf, ico, пустой bmp) этот мой EXE не запускается.
В EXE и в основной проге (которая делает printto) использована некая логика.
Например, я печатаю несколько картинок подряд, пока EXE не "словил" картинку(имя кот. заранее неизвестно), нельзя печатать следующий файл.
1) EXE запустился, с файлом-параметром (результат печати), значит можно давать команду делать следующее printto
2) Если при printto отловилась ОШИБКА (результатов печати не будет), значит можно делать следующее printto
Если ОШИБКА не отловилась и EXE никогда не запустится, то мой "цикл" встанет .
Дмитрий77Т.е. printto не надежен в плане гарантии печати (но ошибку в случае не печати ShellExecute возвращает четко).

Ни фига ShellExecute не надежен. При "ошибке" он обычно возвращает (например при печати ico):
(== 31, meaning SE_ERR_NOASSOC), than according to shellapi.h "There is no application associated with the given file name extension.", which
что просто означает, что нет ассоциации с "printto" в реестре системы(shimgvw.dll,ImageView_PrintTo или другая ассоциация не прописана для данного типа файлов) , а никак не ОШИБКУ в ImageView_PrintTo.
А пустой BMP он тоже пропустит с Err(ShellExecute)=42 (больше 32 - не ошибка), и точно также EXE не запустится и мой цикл встанет.

Как вариант, я конечно могу "ждать EXE в течении разумного времени", но разумность вещь относительная: "печать" 100-страничного документа может занять несколько минут, а обычные 1-2 страницы это 1-2 секунды.

Но по сути вопроса топика, вопрос можно снять за его бессмыслицей.
Ибо нельзя отследить ошибку которой нет.