nsI*Editor::OutputText(nsString& aOutputString);
nsI*Editor::OutputHTML(nsString& aOutputString);
These methods always returns back a Unicode version of whatever is in the content model. It is the
responsibility of the caller then to call whatever converter is required to convert to the appropriate
charset.
Added:
nsI*Editor::OutputText(nsIOutputStream* aOutputStream, nsString* aCharsetOverride = nsnull)
nsI*Editor::OutputHTML(nsIOutputStream* aOutputStream, nsString* aCharsetOverride = nsnull)
These methods output the the current content model to aOutputStream. The document is encoded using the
document defined charset or if the user passes in a non-null value for aCharsetOverride then this
encoding overrides the encoding used by the document.
1. fix for bug 5796, crash on exit. This was a bad, bad memory smudge on my part, easily fixed by doing the right ref counting in the
right places.
2. some preliminary code for M6 block transformations has leaked into this checkin. It's safer than trying to re-code the fix above into
a fresh tree. Unless you're making calls to do block transformations, you won't see any difference.
* added TextEditorTest.cpp, a unit test module for nsTextEditor. It's use is actually commented out since my checkin is happening so late due
to all-day build bustage, and I don't have a Mac handy to verify. With someone's Mac help tomorrow, I can turn it on.
* some minor bug fixes to property handling
added aFirst out param to GetTextProperty, so the caller can know if the first character has the property in the case of aAny=true and aAll=false.
fixed a bunch of places where result was being used incorrectly as a return val from do_QueryInterface
some minor undo/redo fixes to split and join of interior nodes.
trivial to add more properties
finished first cut at SetTextProperty. This triggers lots of crashes in
range/selection code where we're holding onto a stale frame pointer (at
least, that's my best guess.)
synched with Charlie's change-o-rama
added an assert in DeleteTextTxn::Init() checking aNumCharsToDelete vs.
0
NS_ASSERTION(0!=aNumCharsToDelete, "bad arg, numCharsToDelete");
if the number of chars to delete is 0, we shouldn't be creating a
transaction at all. I had never seen this condition arise before
Charlie's checkin, I don't know if he introduced it or if it was a
latent bug I just never tripped over before.
tague%netscape.com
kostello%netscape.com
buster%netscape.com
cmanske%netscape.com
akkana%netscape.com
jfrancis%netscape.com
sfraser%netscape.com