Hi, On Sat, Dec 07, 2002 at 01:19:31PM +1100, Matthew Duggan wrote: > > 4.3.16 sane_verbose_error > > > > This function returns a verbose description of the latest error. The > > returned string consists of one or more complete sentences. It is the > > responsibility of the frontend to break the string into > > managable-length lines. Newline characters in this string should be > > interpreted as paragraph breaks. The function is guaranteed to never > > return NULL. The returned pointer is valid at least until the next > > call to this function is performed. > > > > SANE_String_Const sane_verbose_error(Sane_Handle h) > >
"This function provides a verbose description of the error code returned by the latest call to a SANE function. The returned ... The error description must be set to "" if the latest SANE function did return SANE_STATUS_GOOD." So the intention is: the message stays the same until any other SANE function returns an non-error status code. Everything not returning a status would be ignored. The issue of thread-safety was raised. I've never used threads and I also don't know if thread-safety is necessary for this function but if the following declarion avoids trouble, it's ok, too: void sane_verbose_error(Sane_Handle h, SANE_String *description, SANE_Int max_len); I'm not exactly happy with this function. Mostly because it doesn't provide the error at the point when the error occurs but sometime later. A little brainstorming: What about using the proposed message call-back instead of this function? So the backend would call the callback immediatly, when a fatal error occurs. Fatal means, that it will return anything other than SANE_STATUS_GOOD. This would work for command-line programs but may be messy for graphical frontends. E.g. sane_open ("/dev/scanner") is called, the open system call fails, because of "file not found" and the abyckend calls the message callback with this error message. The callback returns immediately and the backend returns SANE_STATUS_INVAL. Now the frontend would pop up another error message about the STATUS_INVAL. Quite chaotic. Another way would be to extend the SANE_Status values. E.g. the top 16 bits are for backend-local error. So both the standard SANE error code and something that has more information could be stored. sane_strstatus could be used to print it. However, if you want to use messages like "can't open /dev/something" that means dynamic numbering. Not too nice, also. Bye, Henning