переделывай давай

А чего переделывать-то? Я уже сделал одну отрисовку в сессии чтения, что еще там надо?
Алгоритм вполне нормальный -- нет контекста, выдаем в поток картинку; есть контекст -- в поток не выдаем, в любом случае, только одна отрисовка. На контекст выводим куда хотим, и какого хочешь размера (в пределах картинки), вписывая в прямоугольник отрисовки, заданнный точками координат.

------------ Дoбавленo:

Или ты не мне сказал

Тебе.

1) Разве белые люди делают DeleteDC(Bitmap.Canvas.Handle) ???
2) Зачем нужно св-во DrawSource - не пойму
3) Интерфейс пользователя должен позволять Создать объект + (Отрисовать сколько хочешь раз, и каким хочешь макаром) + Уничтожить его
4) У пользователя должна быть возможность установить самостоятельно Point1 и Point2, уже зная параметры картинки, ДО отрисовки
5) Обязательность обработки очереди сообщений - сомнительна.
Например, если отрисовку подключать на OnPaint, то это уж точно противопоказано.
Да и в KOL ее отрабатывать следует KOL-овскими методами. Это, видимо, должно быть внешнее событие, к которому пользователь при желании подключает Application.doProcessMessages
Тут еще есть над чем подумать...

А вообще, ты читал чего-то про этот COM

Не сомнительна -- tsdima специально ее сделал для отработки мультирежима, так как оба метода работают в разных потоках, а то у нас из 10 картинок считывало только одную.
Этого не понял, надо что, писать в буфер, что ли, а прозрачность в буфере у нас не поддерживается, только прямо на контексте можно.


Про этот COM писал tsdima, я сам про него ничего толком не нашел, только что он есть и как его прикрутить, но он уже был прикручен.

Мелкие ошибки я исправлю, а вот с глобальными непонятками, надо разбираться

Мне кажется, не стоит заморачиваться с многократной отрисовкой из буфера, нафиг он не нужен. Компонент хорош для чтения эскизов из папок на лету (для этого он и разрабатывался), остальное прикрутили по ходу пьесы.

Вышесказанное означает, что необходимо обрабатывать очередь сообщений в ЛЮБОМ мыслимом случае.
Фигня - не в любом.
Обязательность здесь относится ТОЛЬКО к ожиданию окончания потока при следующем вызове метода SelectChanges
И никакого отношения не имеет, например, к очереди сообщений
Это все, не считая того, что в приведенном варианте реализации использование объекта ядра вместо обыкновенного флага - удивление легкое вызывает...


Создал объект
Отрисовал его один раз маленьким
Если хочется побольше, или в другом месте - чего, снова винтом шевелить, что-ли ???
Надоело - удалил, чего непонятного-то...

Или второй вариант: ты хочешь его рисовать на чем-то, по событию onPaint
Скажем, супер-пупер PNG, на очень красивом фоне, по событию PaintBox.onBeforeDraw
В этом варианте, надо иметь этот объект не уничтоженным, и уж точно - НЕ обрабатывать очередь сообщений потока
Разве аналогичное является чем-то из ряда вон выходящим



Это есть плохо
Значит у него и надо пораспрошать с пристрастиями
Как же иначе можно отвечать за сделанное... Не этюд же - элемент в дистрибутиве... Да и для всяких мульти-картинок средства есть наверняка...

И на чем его хранить, открывать скрытое окно, на Bitmape хранить не получается, прозрачность теряется, или другой вариант: скопировать копию окна в память (ну или картинку) и на ней отрисовать -- картинка будет лежать в памти и по запросу отрисовываться, но ведь так сначала и было?

Столкнулся еще с одной проблемой, на Bitmap.Canvas.Handle отрисовывать категорически отказывается. В callback методе категорически отказывается считывать правильно указатель на DC Bitmapa в памяти (они разные), что не скажешь о DC окна. А ведь у меня в первом варианте это получалось, так что с упрощением надо повременить, а поюзать дополнительно старый вариант.

Про это что-то писал tsdima, вроде использование флагов не совсем корректно, в случае завершения отрисовки, так как не совсем известно что еще за сообщения шлются, вот он и предложил отрабатывать всю очередь. Я только одного не пойму -- чем это так уж плохо, или чем чревато?

Ну, если захочет ответить, а так придется провести более расширенный поиск?

При исполнении, эта строка
-- создала объект, или нет
Ты его УЖЕ хранишь, коль скоро умеешь им пользоваться
Чего изобретать проблемы-то, не пойму
Их и без изобретательства хватит...

Кстати говоря, этот COM-объект -- это ТВОЯ граната, почему на место никто не положил


Ты хочешь сказать, что это
-- прекрасно работает. А это:
-- нет
Если другое, ну поставь себе в труд выражаться яснее ...


Вы чего гоните
COM-объект знает только контекст, который ему передали
Больше он не знает ничего
Какие нахрен сообщения, которые якобы шлются, для контекста

Да нет, именно это, и именно при чтении контекста Bitmapa в callback'e, в случае Draw, так тот Bitmap там же и оформляется. Ну не совсем правильно выразился, но понял-то ты правильно.
Не знаю, но с флагом не получается нифига, может чего подскажешь толкового?

А это действительно упустили.

Так написано-то одно и то же
Разбиратьсяся надо, а не "юзать"

Galkov, я тут немного подумал -- а зачем вообще шаманские пляски вокруг callback'a, он нужен только, чтобы получить GetStateInfo. Я попробовал все, что можно, оттуда перенести в основной метод, и все так же точно работает. Это кажется более правильным решением.

Что для onLoad основной поток лучше, так это и обсуждать нечего. Можно даже сказать, что асинхронный onLoad -- это просто неправильно.
Получается, что единственная задача callback'a - сигнализация о готовности к рисованию......

Мне кажется это не совсем правильно. Вот что я нашел:



См далее:



Мне кажется, что tsdima прицепил ее правильно, иначе отловить завершение чужого потока не так просто, да и не корректно (я помню, он об этом писал).

О чем вопрос-то, не пойму
"Вышесказанное" в моем посте относится к твоему "Не сомнительна"
"Не сомнительна" - значит надо отрабатывать очередь сообщений.
Мое утверждение в том, что ждать конечно надо, но не факт, что надо месить очередь.

А нашел не совсем в тему. Это API может ждать любой объект ядра. Логичней всего ждать ждать поток в котором сей COM-объект свои безобразия вытворяет.
Вот только хэндла егонного у нас нет, поэтому свой объект и заводится. Вот только смысла ждать его с нулевым таймаутом особого не усматриваю.
Мне кажется, логичней ждать
безо всяких циклов (тогда кстати, без объекта ядра и не обойтись)
Хотя возможны видимо и два варианта, только вместо явной обработки очереди, надо сделать событие onWait, к которому подключать Application.doProcessMessages

---

BTW: Про всякую такую фигню надо сведения не урывками добывать, а какой-нибудь букварь читать. Я читал Рихтера

А у тебя, случаем, ссылки на этот букварь не завалялось?

------------ Дoбавленo:


Ну вот с этим

все безобразие уснуло надолго (повисло просто)



А подорбнее можно ?

Тогда я пас.
Не фига не понимаю, как может COM слать сообщения, не зная ничего -- ему же даже DC никто не сказал




Не завалялось
Вообще-то я на сети снял где-то
Это сканирование бумажной книги, сделанное с помощью "замечательной" программы FineReader
Могу намылить
"Замечательность" в какой-то степени я подправил, но не все... за остальное не обессудь