> hmmmm.....
> ok on line 130 what supposed to happen is that the ole extraction code tests
> the first char of the ole file, the logic is that it the char isnt the char
> that ole is supposed to start with then you get "barf no ole". The actual code
> tests to see if the char is a printable char before it does the test to see if
> the char is actually the right one.. So maybe some insane implementation of
> isprint is allowing 0xd0 as a printable char, so i've put the tests the other
> way around. Try again with the new cvsed one. I'm a bit doubtful that this
> simple fix will change anything, seeing as the standalone wv hasn't had a
> problem with this issue previously, but could someone give the new cvs wv tree
> a check.
>
> >If anybody wants me to email them a few samples files I'm having problems with
> >then I can do, I'll not post them to the list since it'll be about 200K and
> >that's not too nice over slow dial-up links :-)
>
> You can always mail one or two to me, but id bet that they'll work on my setup
> already.
>
> btw, putting in that macro to use __LINE__ and __FILE__ has really been an
> incredibly helpful remote debugging facility, i'd reccomend it for anyone.
I should have mentioned, I'm using the packaged 0.7.4 build rather than the
latest from CVS. But hey, I suppose I should learn how CVS works at some point
in my life anyway ;-) so I'll get back to you when I've figured it out any
managed to build my own copy.
Yours,
Ian.
-- #ifndef __COMMON_SENSE__ | Ian Phillips #include <std_disclaimer> | TIBCO Software Inc. #endif | www.TIBCO.com