かにの泡ぶく

_ ややこしいTWAIN（その2）。

最近また、TWAINを扱うコードを書いている。

前回は、Native転送だけでよかったので、まだなんとかなっていたが今回は、16bit画像や48bit画像を取り込まねばならず、そうなると、最低でもMemory転送が必要になる。

たんにMemory転送をサポートするだけであれば、そう大変では無いのであるが問題は、TWAINをコールし、先方（データソース）に処理を渡すとき、どっちの転送方式になるのかアプリ側（クライアント側）では予想できないという点。

例えばGUI出すモードでスキャナを駆動することを想定しよう。

GUI上でユーザーが例えば24bitRGBでスキャン指定すればそのときはNative転送でOKだが、48bitRGBでスキャン指定されたらMemory転送にしないといけない。GUI閉じられて実際にスキャン開始されるまで、アプリ側ではどっちになるのかわかんないのだ。

処理をディスパッチするとロジックが綺麗じゃなくなるので、全部Memory転送に統一しちまうということも検討してみたが、TWAINの規格として、Native転送は最低限度サポートせよということだし、万一、Native転送しかサポートしていない機器があったら困るしで、やっぱNative転送は外せない。

Native転送とMemory転送では、データを受けるための仕組みが違うため、アプリ側ではそれぞれに応じて処理の切換が必要なのだ。内部構造的には、TWAINというのはアプリのいちIFにすぎなくしたいので、できれば独立性を高めて実装したいのだけど、アプリのメッセージループにまで食い込んでくるTWAINのイベントハンドリングは、どんなに綺麗に実装しようとしてもアプリ側の実装が汚くなってしまう。

それがさらに、データ転送直前でのモード切替を余儀なくされるとなると、アプリ側の構造はもう、TWAINにかなり依存した設計にせざるを得なくなってしまう。

う〜〜〜〜〜〜〜ん、なんとかならんものか、この入り組みかた。