- Topics - 10
- Replies - 23
- Total Posts - 33
For those who are interested: I further investigated the container that is passed from the Data Source to the application (MSG_GET) and vice-versa (MSG_SET).
When I look into memory at the address allocated for the TWON_ONEVALUE container during the MSG_GET of ICAP_XRESOLUTION I can see:
where the first doubleword is Frac+Whole, and the preceeding word (0x0007) is TWTY_FIX32 twain type. Frac, the upper word, is 0x0258 (=600 dpi) and I already said in my previous post that Whole and Frac get exchanged. The word 0xXXXX that preceedes the container is not part of it, but for the sake of completeness its values is 0x0032.
When I allocate the container to perform a MSG_SET of the ICAP_XRESOLUTION, on the contrary, the memory looks like this:
(0x00C8 = 200 dpi) and when I call the DSM entry point I invariably get a TWCC_BADVALUE return code, even if I exchange the words in the Item (0x00C80000) to mimic the MSG_GET arrangement.
By manually changing the contents of the memory, I discovered that the only way to receive the TW_OK status when returning from a call to the DSM entry point, is to set 0xXXXX to the exact same value that it is set when returning from a MSG_GET (0x0032). Any other value makes the MSG_SET fail.
Nonetheless, returning an OK twain status when returning from such a call, the resolution is supposed to be set to the new value… but as I make a successive query (with a further MSG_GET), the resolution is still set to 600 dpi (with Whole and Frac exchanged).