Home › Forums › TWAIN Classic › how to develop a twain driver without UI ?
- This topic has 6 replies, 2 voices, and was last updated 16 years, 10 months ago by gabe.
- AuthorPosts
Hello,
i’m trying to implement a twain driver, and i would like to make a skeleton before attacking serious stuffs. So, i would like to make a driver as simple as possible, so, without any UI.
I use the sample contained into the SDK (twac_32) and Gimp to test my driver; and i have already made the first steps:
-> The .ds that i generate is seen by Gimp
-> i’ve managed the first calls to DSM_Entry (DAT_IDENTITY and DAT_CAPABILITY messages)And now, i don’t understand how to manage the DAT_USERINTERFACE message. As I don’t want any UI, i don’t know what must I do when I receive this message. I try to call NotifyXferReady(), but it don’t seems to be the good solution.
At this step of my development, i’m stuck. DS_Entry is called infinitely with this triplet: DG_CONTROL / DAT_EVENT / MSG_PROCESSEVENT
FYI, here is my “supported caps array”:
static TW_UINT16 gSupportedCaps[SUPPORTEDCAPS] =
{ CAP_SUPPORTEDCAPS, ICAP_XFERMECH, ICAP_COMPRESSION, ICAP_ORIENTATION, CAP_XFERCOUNT,
ICAP_UNDEFINEDIMAGESIZE, CAP_INDICATORS };Thanks for for advices 🙂
R.P.
Re,
I progressed in my understanding of the foncitonnement of Twain, and I made some changes in my program.
My supported caps looks like this from now:
static TW_UINT16 gSupportedCaps [ SUPPORTEDCAPS] = {CAP_SUPPORTEDCAPS, ICAP_XFERMECH, CAP_XFERCOUNT, CAP_UICONTROLLABLE};I succeed in treating (correctly I hope) the following triplets:
-> DG_CONTROL / DAT_IDENT ITY / MSG_GET
-> DG_CONTROL / DAT_IDENT ITY / MSG_OPENDS
-> DG_CONTROL / DAT_CAPABILITY / MSG_SETThen, I receive Event, and I generate the event MSG_XFERREADY
But now, I wait for the triplet:
DG_IMAGE / DAT_IMAGEMEMXFER / MSG_GET
but I do not receive it.Have you an idea of what I forgot?
I thought showing the Ui was a part of the twain requirement? If I ask a source to show the Ui and it doesn’t I’m going to be pretty… unpleased.
.Ok, but the driver I’m making don’t need UI. It’s a driver for a digital camera, and the purpose is medical imagery. So i have to make sure that user cannot modify parameters of the camera.
I made something. I wonder if it’s dangerous. In my PS_Entry, when I receive an event, and my camera is ready to shoot, i set the message’s pData struct to MSG_XFERREADY:
if ((!m_appIdent_ity.Id) || (m_appIdent_ity.Id == twMsg.pSrc->Id))
{
if ( twMsg.MSG == MSG_PROCESSEVENT )
{
twRc = TWRC_DSEVENT;
pTW_EVENT pEvent = static_cast(twMsg.pData);
if ( pDsManager->IsReadyForXFerr() ) //pDsManager is an object that manage the driver (states, status, errors, ...)
{
pEvent->TWMessage = MSG_XFERREADY;
}
}
}What do you think about this?
ps: what the hell is happening on this phpbb forum with the word “ident ity” ? I’m forced to insert a white space else the word is replaced by “no”.
>>What do I think of this…
I think that the first time a user tries to use ms word to acquire an image that you’re going to get a call if they can find your number. If you don’t want the user to change a setting don’t tie that setting to your Ui – you’re writing the Ui, you can put whatever you want in there or not.
Also, think about what version of twain you’re writing you driver for. If you’re targetting twain 1.5 compability you (per the spec – chapter 3-64) must support:
CAP_SUPPORTEDCAPS MSG_GET required
CAP_XFERCOUNT All MSG_* operations required
ICAP_COMPRESSION All MSG_GET* operations required
ICAP_BITDEPTH All MSG_* operations required
ICAP_BITORDER All MSG_* operations required
ICAP_PLANARCHUNKY All MSG_GET* operations required
ICAP_PHYSICALHEIGHT All MSG_GET* operations required
ICAP_PHYSICALWIDTH All MSG_GET* operations required
ICAP_PIXELFLAVOR All MSG_GET* operations required
ICAP_PIXELTYPE All MSG_* operations required
ICAP_UNITS All MSG_* operations required
ICAP_XFERMECH All MSG_* operations required
ICAP_XRESOLUTION All MSG_* operations required
ICAP_YRESOLUTION All MSG_* operations requiredand if you’re aiming for a more current spec you’ll have to add more.
…And yeah, none of that was really in answer to your question, but I do have something that may be useful for you: have you taken a look at the shell provided by dosadi? Take a look at ‘GenDS Toolkit’ over here: http://www.dosadi.com/beta_products.htm
Oh and take my comments lightly, I’ve never written a driver – but I have definate feelings for drivers that don’t follow the spec and the devs responsible.. 😉
.
Ok, thank you for your advices, I’m going to take a look on the shell provided by dosadi.
Anyway, the driver I’m making won’t be used by Ms Word. In fact, it will be used only by one application… but well… for the moment, i don’t know anything about this application :/
Concerning the capabilities that must support my driver, I’ve seen that in the twain documentation. But, well, as my driver will be used by only one application, is it indispensable to implement all these capabilities?
Thank you once more for your advices. The delay i have obtained to make this driver is short (damned commercial strategy) and all informations are welcome 🙂
And ho, maybe you noticed that my code is c++ (not c code). All my driver is made in c++, respecting usual patterns (const conformity, RAII resources management, addressing optimization, etc.). If my code can interest somebody, I’ll be glad to propose you a simplified and license free version.
I’d more than happy to take a look at it.
my email address is in my profile..
- AuthorPosts