Home › Forums › TWAIN Classic › Specification Capability Negotiations Question/Concerns
- This topic has 2 replies, 3 voices, and was last updated 17 years, 5 months ago by bijulsoni.
- AuthorPosts
I am needing a bit of a clarification on the negotiation of capabilities… I am working with a Fujitsu fi-5650C as my current test source utilizing the latest Twain driver from the manufacturers sight. I have other scanners available but as TWAIN is a specification I am hoping that by implementing against one source in a generic fashion will produce a component that works against any data source.
(I have a few question here so I will mark the proceeding statements numerically and seperate the question itself with a space.)1.
The specification states that a MSG_GETCURRENT if supporrted by a source should return either a TW_ONEVALUE or TW_ARRAY holding the current value for the specified capability. It points out that it can be used in place of a MSG_GET in a situation when you are only trying to retrieve the current value.This lead me to believe in a situation where I only need the current value it should be quicker to utilize MSG_GETCURRENT as it should return the same current value as MSG_GET. Is this correct?
2.
The specification implies that ICAP_BITDEPTH is dependant on the current value of ICAP_PIXELTYPE. I have found that on issuing a MSG_GET for ICAP_BITDEPTH the source will return a TW_ENUMERATION specifying the supported values and the current value for the capability without a problem, but if you follow up by utilizing a MSG_GETCURRENT or MSG_GETDEFAULT the source is prone to return a current and default value that do not exist in the list of supported values offered by MSG_GET.I am curious if I missed something in the specification that stated that this should be the case or if I may have stumbled across I bug in the driver?
This has lead me to believe that in a generic implementation of Twain in an application a MSG_GET if supported should be utilized as a prefered method of retrieveing the current value and MSG_GETCURRENT only if the former is not available for the capability, is this an accurate presumption?3.
I also am left slightly concerned by the information provided for ICAP_COMPRESSION’s source implementation. From reading that section I was left to believe the source would be responsible for modifying the list of supported values for Compression based on the current value of ICAP_IMAGEFILEFORMAT; simular to the way the supported values are adjusted by the source for ICAP_BITDEPTH. I have found with this driver that this is not the case. I have to manually restrict the supported compression values based on the file format.This has lead me to believe that in a generic implementation of Twain in an application some dependant capabilites will need to be restricted manually to make up for driver writers that chose to take shortcuts around the specification. Is this an accurate assumption?
I have also found on ICAP_GAMA the source is returning from MSG_QUERYSUPPORT a value indicating it supports an operation that when utilized return coditions indicating the operation is not supported. The sample data source provided at the ORG site also has many capabilities that err in this fashion.
I see some of these discoveries to be discouraging and believe there should be a movemnet in the Organization (perhaps in the 2.0 Standard) to qualify a more rigid certification process that Twain compliant devices must adhere to in order to boast Twain support.
Any comments or suggestions will be apprieciated.
Session timed out… Should not have show up as guest… 😀
hi .
I read your question i think the following link will solve your problemhttp://www.codeproject.com/dotnet/twaindotnet.asp
My Problem
I am implementng Scanning Solution for C#.NET using TWAIN_32.DLL.It will be helpful to me if u show me how to get Supported values of capability in
any of the 4 containers, means how to retrieve supported values for a given capability.- AuthorPosts