Home › Forums › TWAIN Classic › TW_CUSTOMDSDATA question
- This topic has 6 replies, 3 voices, and was last updated 16 years, 12 months ago by spike.
- AuthorPosts
From the TWAIN specification, it looks like the structure for TW_CUSTOMDSDATA is 4 bytes for the length followed by an array of bytes containing the data. However, I’ve found that Fujitsu puts a memory pointer after the length instead of the actual data.
Which is correct: An array of bytes or a pointer to the array of bytes?
its a pointer
OK, this is really weird – my copy of the twain.h file (version 1.9 March 2000) declares the TW_CUSTOMDSDATA structure as
typedef struct {
TW_UINT32 InfoLength; /* Length of Information in bytes. */
TW_HANDLE hData; /* Place holder for data, DS Allocates */
} TW_CUSTOMDSDATA, FAR *pTW_CUSTOMDSDATA;This is the original declaration introduced in the TWAIN 1.7 spec! On Windows, a TW_HANDLE is a global handle, the kind you use GlobalAlloc, GlobalFree, GlobalLock and GlobalUnlock on. In my experience, data sources (Fujitsu, Canon, HP) follow this declaration – the 2nd field is a (4-byte) HANDLE to global memory, or HGLOBAL.
The TWAIN spec seems to be FUMTU on this subject: Not only do later revisions contain an incompatible and confusing declaration of TW_CUSTOMDSDATA, but different sections make contradictory claims about this feature. Under DG_CONTROL/DAT_CUSTOMDSDATA/MSG_GET it says
This operation is used by the application to query the data source for its current settings, e.g.
DPI, paper size, color format. The sources settings will be returned in a
TW_CUSTOMDSDATA structure. The actual format of the data in this structure is data source
dependent and not defined by TWAIN.Of course, TWAIN does define the format of the data in that structure. I suppose the author meant to say ‘…the format of the data referenced by the InfoData field is data source dependent…’. Here’s the definition of that structure, except that in my experience the declaration is tragically misleading about the InfoData field:
typedef struct {
TW_UINT32 InfoLength; /* Length (in bytes) of data */
TW_UINT8 InfoData[1]; /* Array (Length) bytes long */
} TW_CUSTOMDSDATA, FAR *pTW_CUSTOMDSDATA;
…
The format of the data contained in InfoData will be data source specific and will not be
defined by the TWAIN API. This structure will be used by an application to query the data
source for it’s current settings, and to archive them to disk. Although the format for this
custom data is not defined by TWAIN, source implementers are encouraged to use a ASCII
representation for the custom data to be used for settings archival. A Windows INI style
format would be easy to implement and allow for additional features to be added without
breaking backwards compatibility.In my experience, several major vendors have implemented the original (1.7) spec – the 2nd field of the TW_CUSTOMDSDATA structure is a 4-byte Windows HGLOBAL. Those same vendors have also followed that advice about making their custom DS data a string of ASCII text in INI-file format or something like it. Note that the spec calls for the custom data to contain the entire settings of the DataSource: I just encountered a DS whose authors missed that part…
Why does it take 10 years to correct things like this in the spec? I volunteer to edit this part of the spec…
wha? twain hard to work with? misleading at times? shock outrage…. ha, yeah but if it were easy we’d… oh.. yeah – we’d like it more and users would have a better experience with better compatibility. this stuff used to upset me, but it’s gotten more amusing. and there aren’t many alternatives.. ha – are there really any alternatives? seriously, I don’t think there are. WIA starts to come to mind but it would be tough for me to say that it is a real alternative considering the driver problems. I always wanted to look at ISIS but I couldn’t ever find an api for it.
Thanks for the information. It would be nice if the specification was updated to help avoid “who is correct” questions. I don’t think that’s too much to ask.
but “who is right” is tricky even when the api is clear as when the vendor says ‘twain compatible’ they might mean to version 1.4 of the spec or they could be talking about version 1.9, but really it just means is that a driver exists. Too bad more (any?) vendors don’t say which version they’re talking about, but I think it adds a bit of spice to the mix – keeps it interesting.
spike – what ds did you run into that supported customdsdata but didn’t provide for all of the settings? (wait, no I think its coming to me telepathically – HP?)
gabe
Hi Gabe – Ah probably you are receiving ‘HP+TWAIN…DANGER…DANGER’ telepathically because the collective unconscious of TWAIN developers is always transmitting that…
but the gadget I just met is a check scanner. Very cool gadget with all kinds of wonderful TWAIN features which are actually (*gasp*) documented. It’s just that they are (ab)using CUSTOMDSDATA to do what should be done with custom capabilities, instead of storing the entire settings. There is just the one paragraph about it in the spec – unfortunately, most of the spec is so redundant that you don’t expect anything crucial to be stated in just one place!- AuthorPosts