Re: HTBlackHole problem & dealing with stream return codes in HTTee
In message <01BACEEB.509B4760@pclab19.mimuw.edu.pl>, Maciej Puzio writes:
>user clicks Cancel button in the dialog box? The file is not saved to the disk
>, but the
>message "Reading (2% of 3.8M)" still appears and changes slowly from 1% to 100
>This really can lead to a deep confusion...
>Why's that? The library creates a stream stack to deal with the transmitted da
>after parsing the MIME headers. In our example, the body is in the ZIP format,
> so the
>library decides that it should be saved to the disk (see HTConverterInit() in
>It constructs then a HTSaveLocally stream using HTSaveLocally() function
>(HTFWrite.c). This function prompts the user for a file name (via HTAlert). If
> it gets
>NULL (which means an error, e.g. click on Cancel button), the HTBlackHole is r
>to the HTSaveLocally() caller. And instead of cancelling the connection, the d
>flowing from the network and getting to the HTBlackHole, where it's discarded.
>The easiest solution is to change the result codes returned in
>HTBlackHole_put_character, HTBlackHole_put_string and HTBlackHole_write
>from HT_OK to HT_ERROR.
Err... that would make the blackhole useless for its sole purpose: to
consume the data.
It seems like the problem is that the HTSaveLocally() uses the black hole
in the first place -- it's not consuming the data, but rejecting it.
If HTAlert fails, HTSaveLocally should return an
error (or a new kinds of stream that reports HT_ERROR all the time), no?