| content assistant bypasses StyledText widget [message #142204] |
Mon, 16 February 2004 07:00  |
Eclipse User |
|
|
|
I posted this on the swt group with no response, but maybe it is more
appropriate here...
3.0M5
Can anyone speak to the Eclipse philosophy on VerifyListeners?
I have a StyledText widget that I have called addVerifyListener() on. I use
this listener to enforce readonly behavior on certain portions of the text.
However, the CompletionProposalPopup calls AbstractDocument.replace(int pos,
int length, String text) directly on the document instead of calling
StyledText.replaceTextRange(int start, int length, String text). This
bypasses the VerifyListener notification and modifies the text directly.
Therefore, I have no hook to prevent edits selectively. It seems like
applying
a proposal is a UI event like Paste or keystrokes (for which I receive
verify events), but it is not
treated the same way.
My ideal situation would be that I could bring up the content assistant and
see what it suggests, but selecting one of the options would be subject to
the verify listener.
Is this the way completion proposals "should" work? Has anyone found a good
way around this?
|
|
|
| Re: content assistant bypasses StyledText widget [message #142238 is a reply to message #142204] |
Mon, 16 February 2004 08:36  |
| Eclipse User |
|
|
|
Ernest Pasour wrote:
> Can anyone speak to the Eclipse philosophy on VerifyListeners?
>
> I have a StyledText widget that I have called addVerifyListener() on. I use
> this listener to enforce readonly behavior on certain portions of the text.
> However, the CompletionProposalPopup calls AbstractDocument.replace(int pos,
> int length, String text) directly on the document instead of calling
> StyledText.replaceTextRange(int start, int length, String text). This
> bypasses the VerifyListener notification and modifies the text directly.
> Therefore, I have no hook to prevent edits selectively. It seems like
> applying
> a proposal is a UI event like Paste or keystrokes (for which I receive
> verify events), but it is not
> treated the same way.
StyledText is just a controller for the underlying model, in this case
an instance of IDocument. Not all document modifications are performed
through the StyledText. Examples are code completion, but also
refactoring and really any of the advanced editing capabilities not
directly supported by StyledText. The distinction between UI and non-UI
events is not so clear e.g. with refactoring.
IDocument informs its registered IDocumentListeners about changes to its
model - however, it does not support validation / vetoing of a change.
Validation of read/write is done by the editor framework on a
per-document basis (see AbstractTextEditor.validateEdit), but not for
specific text regions.
-> You will probably have to implement your own Document that provides
the read-only regions.
-tom
|
|
|
| Re: content assistant bypasses StyledText widget [message #142313 is a reply to message #142238] |
Mon, 16 February 2004 10:10 |
| Eclipse User |
|
|
|
Tom,
Thank you very much for the response. I will work at it from the Document
subclass angle.
Ernest
"Tom Eicher" <eclipse@tom.eicher.name> wrote in message
news:c0qgqr$e3r$1@eclipse.org...
> Ernest Pasour wrote:
> > Can anyone speak to the Eclipse philosophy on VerifyListeners?
> >
> > I have a StyledText widget that I have called addVerifyListener() on. I
use
> > this listener to enforce readonly behavior on certain portions of the
text.
> > However, the CompletionProposalPopup calls AbstractDocument.replace(int
pos,
> > int length, String text) directly on the document instead of calling
> > StyledText.replaceTextRange(int start, int length, String text). This
> > bypasses the VerifyListener notification and modifies the text directly.
> > Therefore, I have no hook to prevent edits selectively. It seems like
> > applying
> > a proposal is a UI event like Paste or keystrokes (for which I receive
> > verify events), but it is not
> > treated the same way.
>
> StyledText is just a controller for the underlying model, in this case
> an instance of IDocument. Not all document modifications are performed
> through the StyledText. Examples are code completion, but also
> refactoring and really any of the advanced editing capabilities not
> directly supported by StyledText. The distinction between UI and non-UI
> events is not so clear e.g. with refactoring.
>
> IDocument informs its registered IDocumentListeners about changes to its
> model - however, it does not support validation / vetoing of a change.
> Validation of read/write is done by the editor framework on a
> per-document basis (see AbstractTextEditor.validateEdit), but not for
> specific text regions.
>
> -> You will probably have to implement your own Document that provides
> the read-only regions.
>
> -tom
>
|
|
|
| Re: content assistant bypasses StyledText widget [message #142391 is a reply to message #142238] |
Mon, 16 February 2004 14:21 |
| Eclipse User |
|
|
|
OK, I'm stumped. Is there a way to hook in to create my own Document
subclass instead of a PartiallySynchronizedDocument instance? Without
having to replace the .java file association or copy a lot of code from
TextFileDocumentProvider and TextFileBufferManager.
"Tom Eicher" <eclipse@tom.eicher.name> wrote in message
news:c0qgqr$e3r$1@eclipse.org...
> Ernest Pasour wrote:
> > Can anyone speak to the Eclipse philosophy on VerifyListeners?
> >
> > I have a StyledText widget that I have called addVerifyListener() on. I
use
> > this listener to enforce readonly behavior on certain portions of the
text.
> > However, the CompletionProposalPopup calls AbstractDocument.replace(int
pos,
> > int length, String text) directly on the document instead of calling
> > StyledText.replaceTextRange(int start, int length, String text). This
> > bypasses the VerifyListener notification and modifies the text directly.
> > Therefore, I have no hook to prevent edits selectively. It seems like
> > applying
> > a proposal is a UI event like Paste or keystrokes (for which I receive
> > verify events), but it is not
> > treated the same way.
>
> StyledText is just a controller for the underlying model, in this case
> an instance of IDocument. Not all document modifications are performed
> through the StyledText. Examples are code completion, but also
> refactoring and really any of the advanced editing capabilities not
> directly supported by StyledText. The distinction between UI and non-UI
> events is not so clear e.g. with refactoring.
>
> IDocument informs its registered IDocumentListeners about changes to its
> model - however, it does not support validation / vetoing of a change.
> Validation of read/write is done by the editor framework on a
> per-document basis (see AbstractTextEditor.validateEdit), but not for
> specific text regions.
>
> -> You will probably have to implement your own Document that provides
> the read-only regions.
>
> -tom
>
|
|
|
|
| Re: content assistant bypasses StyledText widget [message #142594 is a reply to message #142496] |
Tue, 17 February 2004 08:43 |
| Eclipse User |
|
|
|
Well, I am attempting to create a java editor that's exactly like the normal
java editor (including being hooked into all the normal tools that the java
editor is hooked into) except that the parts where I generate code are
readonly. So the best situation for me is to subclass the existing document
and view so that I don't lose all the normal behavior. I've already
subclassed the view, so it sounds like I'll need to see if I can come up
with an acceptable solution without subclassing the document.
Thanks for your response.
Ernest
"Tom Eicher" <eclipse@tom.eicher.name> wrote in message
news:c0si1p$nl6$2@eclipse.org...
> Ernest Pasour wrote:
> > OK, I'm stumped. Is there a way to hook in to create my own Document
> > subclass instead of a PartiallySynchronizedDocument instance? Without
> > having to replace the .java file association or copy a lot of code from
> > TextFileDocumentProvider and TextFileBufferManager.
> > Ernest Pasour wrote:
>
> What you want to do (an form-like editor with non-editable areas) sounds
> not like something you can accomplish inside the standard editors -
> you'll probably need your own editor type where you can either enforce
> the write-protected areas in your document or in your viewer.
>
> -tom
>
|
|
|
Powered by
FUDForum. Page generated in 0.26740 seconds
Home