- Topics - 9
- Replies - 583
- Total Posts - 592
Ah, then my advise comes from someone with experience consuming a driver not from one with experience writing one, but here it is.
Are there really settings for each of the 4 images you are going to return? Or is it the case that you ‘re going to return 4 images and the user has no control? If you are always going to return 4 images and the user doesn’t control the resoltions (or need to) then I don’t think it is a very big deal – Report the resolution that you return in the twImageInfo after you send the image and it’ll get worked out.
Or, support ExtendedCaps. But,.. I dunno. I could be the case that ExtendedCaps gets a lot more use from other developers but I don’t use it at all,.. and then again maybe I would use extendedCaps more if I saw it being supported by more vendors – hard to say from here
I would put the mirc string in a custom extendedImageInfo, over 0x8000 is reserved for custom. Just return the twStr255 in there and I think a lot of people will bump into it even without your extremely well documented api available from your website or your spectacular support staff who know exactly what ‘custom extendedImageInfo’ means and what the Id is for your Mirc string.
Also, (and this next part has nothing to do with your question) it wouldn’t hurt to include your twain header on your CD for people writing apps. Kodak does this and I gotta say, it helps a lot.
If you haven’t looked thru the GenDs sample from Dosadi, it may help you.