extending EditorKit
Hi,
I want to write a Java applet wysiwyg text editor which understands a
simple markup language similar to Restructured Text.
I'm not a particularly experienced Java programmer and I'm new to Swing
so I may be wrong, but I think a good approach would be to use a Swing
JEditorPane with a custom EditorKit and Document.
I've written a barebones test application in which my custom EditorKit
and Document classes extend DefaultEditorKit and DefaultStyledDocument
respectively. This gives me a working editor however, I was expecting
to be able to insert styled text into my Document but I'm seeing text
with the default style in the display.
To add styled text I'm doing something like this -
document.insertString(document.getLength(), "This text should be big",
getStyle("bigtext"));
where 'getStyle' retrieves a SimpleAttributeSet from a Hashtable.
I'd really appreciate it if anybody could point me in the direction of
some example code or suggest an alternative methodology if I'm going
about this the wrong way.
Greg Hamilton
___
Advanced-swing mailing list
[EMAIL PROTECTED]
http://eos.dk/mailman/listinfo/advanced-swing
Re: JTextArea is a memory hog!
Joe Consumer <[EMAIL PROTECTED]>Joe Consumer wrote:
Christain,
Thanks for the info. THe problem seems to be that
OptimizeIt doesn't seem to show these objects being
GC'ed even at a slow pace.
The finalizer thread runs at a low priority
in the hot spot vm.
What is the fix?
Do not use AbstractDocument :-)
How do you patch AbstractDocument so
that it doesn't create all these AbstractElements?
You can't avoid creating the elements. But
you can avoid them to be finalized by removing
the finalize() method.
/**
* Finalizes an AbstractElement.
*/
// ## patched
// protected void finalize() throws Throwable {
// AttributeContext context = getAttributeContext();
// context.reclaim(attributes);
// }
My tests showed, that the memory impact of not
executing the finalizers is very low compared
to the objects hanging around.
You could still patch this because you could simply
implement the Document interface. Is it creating them
in createElement().
This means rewriting the complete javax.swing.text
package.
Why does it create them and then
all of a sudden ditch them?
May, the view creates a default document and the you set
another (your) document. The the default document is not
used anymore. Use a constructor which immediately sets your
document.
Shouldn't it create them
and hang onto them while the JTextArea is in use?
IMHO it does until the document changes. See scenario above
--
Christian Pesch - Product Maturity Manager
CoreMedia AG - http://www.coremedia.com - 0700-COREMEDIA
___
Advanced-swing mailing list
[EMAIL PROTECTED]
http://eos.dk/mailman/listinfo/advanced-swing
