Version: (using KDE Devel) Installed from: Compiled sources OS: Linux Type some text. Insert an image inline. Type some more text. Save the document. Open it back. The ANCHOR hasn't been written out to the file. So you get '#' in place of where the image is supposed to be and the image is no longer inline. kword is from today's CVS.
Subject: Re: New: kword anchors not being saved On Tuesday 24 June 2003 09:18, you wrote: > Type some text. > Insert an image inline. > Type some more text. > Save the document. > Open it back. > > The ANCHOR hasn't been written out to the file. > So you get '#' in place of where the image is supposed to be and the image is no longer inline. I can't reproduce that. And there was no change in that area at all. I changed libkotext in a binary-incompatible way though, so maybe you didn't recompile kotext+kword and this leads to a wrong behaviour (wrong virtual method being called)? Please try recompiling koffice - does it still happen?
6 hours after cvs-clean and recompilation, it still doesn't work :(
I recompiled abs everything all over again, deleted my $KDEHOME and I can still reproduce. So it's not a BIC problem. David, are you using qt-copy (QT 3.2 beta 2)? I think it may be a QT bug... Saving a file with just a single inline image, KWTextParag::save() correctly calls KWAnchor::save() (via "customItem->save( formatElem )") but "parentElem.ownerDocument().isNull()" reports "true" in KWAchor::save(), which doesn't sound right at all. Depressingly, "doc.isNull()" returns "false" but "formatElem.ownerDocument().isNull()" returns "true" (when they should both return the same thing, which should be "false" [1]), where these tests are placed right after "customItem->save". [1] Disclaimer: I generally don't use QT's XML classes because I don't have a use for them so what I'm saying may be complete rubbish...
*** Bug 60337 has been marked as a duplicate of this bug. ***
So it was a QT bug after all. Thanks for fixing in qt-copy, David. Everything works now.