Transfer of multiple images

[Oleh Topics - 0Replies - 0Total Posts - 0]

Hi,

I’m creating a Twain DS for a user controller camera, and have question regarding to multiple images transfer. I Would appreciate if someone can answer them. In my case, user can take picture by pressing a button on camera, so I’m trying to see how will scenario work with applications that support multiple images and user presses button several times.

Q1. In the scenario when application supports unlimited amount of images ( CAP_XFERCOUNT is negotiated to -1 ) and TWAIN is in state 5 – DS enabled.
As far as I understand following possible scenario should work:
a. User presses button. my DS calls XFERReady callback. We are in state 6
b. App requests image using one of the methods.
c. DS transfers image, and responds with TWRC_XFERDONE once everything is transmitted
d. App calls DG_CONTROL/DAT_PENDINGXFERS/MSG_ENDXFER, we respond with 0 in count field, since there are no more images. This results in State 5
e. App waits further one ( doesn’t call disableUI ).
f. User presses button on scanner. DS calls XFERReady and steps b…f repeat
Is that correct scenario? I’m using twacker to test it. However once transfer of 1 images is done and MSG_ENDXFER with 0 count is replied, twacker will not accept images anymore, although visually it claims that it is still in state 5. This looks like bug in twacker to me.

Q2. What if CAP_XFERCOUNT is negotiated to 1? According to documentation this means that DS should send not more then 1 image per session. But what is considered session? Does it mean between showUI and hideUI calls? Or is session amount of images transferred until we got to state 5, so in Q1, step F is already second session?

Q3. Rather theoretical scenario, but still. If user is very fast ( or application is slow ), and he makes multiple images while transfer of previous image is still ongoing. This means that in scenario 1, step D, we can keep responding with count 1 because every time while we transferred
current image, user manager to take new image.
Is that correct?

Thank you.

[markm Topics - 0Replies - 0Total Posts - 0]

Q1. In the scenario when application supports unlimited amount of images ( CAP_XFERCOUNT is negotiated to -1 ) and TWAIN is in state 5 – DS enabled.
As far as I understand following possible scenario should work:
a. User presses button. my DS calls XFERReady callback. We are in state 6
b. App requests image using one of the methods.
c. DS transfers image, and responds with TWRC_XFERDONE once everything is transmitted
d. App calls DG_CONTROL/DAT_PENDINGXFERS/MSG_ENDXFER, we respond with 0 in count field, since there are no more images. This results in State 5
e. App waits further one ( doesn’t call disableUI ).
f. User presses button on scanner. DS calls XFERReady and steps b…f repeat
Is that correct scenario? I’m using twacker to test it. However once transfer of 1 images is done and MSG_ENDXFER with 0 count is replied, twacker will not accept images anymore, although visually it claims that it is still in state 5. This looks like bug in twacker to me.
In programmatic mode (ShowUI == FALSE) once the driver goes to state 5 (due to TW_PENDINGXFERS.Count == 0) the driver must return to state 4, and then reissue DG_CONTROL / DAT_USERINTERFACE / MSG_ENABLEDS.

Q2. What if CAP_XFERCOUNT is negotiated to 1? According to documentation this means that DS should send not more then 1 image per session. But what is considered session? Does it mean between showUI and hideUI calls? Or is session amount of images transferred until we got to state 5, so in Q1, step F is already second session?
Yes, as indicated above CAPX_XFERCOUNT will end the capture phase, returning the driver state to 5, which should then be taken back down to 4.

Q3. Rather theoretical scenario, but still. If user is very fast ( or application is slow ), and he makes multiple images while transfer of previous image is still ongoing. This means that in scenario 1, step D, we can keep responding with count 1 because every time while we transferred
current image, user manager to take new image.
Is that correct?
I would recommend sticking with -1, because that indicates that there’s an unknown number of images waiting to be transferred. One thing that may be helpful would be to report a value of TRUE for CAP_FEEDERLOADED when an image is ready to be transferred. It would be easy for applications to poll for this. A more advanced solution using events can also be accomplished using CAP_DEVICEEVENT.

[Oleh Topics - 0Replies - 0Total Posts - 0]

Thanks a lot for the reply.
Regarding first question – is it also like that for (ShowUI == TRUE)?

[Author]

Posts