- This topic has 1 reply, 2 voices, and was last updated 13 years, 10 months ago by .
-
Posts
-
One of my users is having the following problem with a DS Dual3 1.0 data source under Windows:
DAT_IMAGENATIVEXFER / MSG_GETreturns TWRC_XFERDONE, but the pointer returned by the call is NULL instead of being a global memory handle.
I can’t see any mention in the TWAIN specification of this being a legitimate result of the call. If the return code is not an error code, then surely a valid handle should be passed back to the calling program?
Am I right that this is invalid behaviour by the data source?
Has anyone else come across this behaviour, with this data source or others?
Any ideas as to what might be causing the error?
Any suggestions for working round it?(I should add that this is production code and has worked well for many people with many different data sources, so if the bug is ours then it must be a pretty specialised one)
You say your code works with many different DS’s but fails with a particular one. That’s a strong indication (but not a guarantee) that the problem is in that DS. You can switch to a memory or file transfer or contact the vendor to try to get the bug fixed.
The TWAIN specification says DS’s are required to support native transfers but very few applications use this transfer method. Vendors usually have a suite of apps they use for Quality Assurance testing. This bug would slip right through QA if the DS is not tested with an app that uses native transfers.