TokenTokenMaker and hex in assembly

[robert]

Don't worry about asking lots of questions. It's good to know that folks are using the library other than just me!

I believe the darker yellow colored region is the default "mark all" color. I think the problem here is twofold. First, you still have the default mark occurrences functionality enabled, which you don't want to do since you're providing your own substitute functionality with MarkAllOccurrencesSupport. Not really a problem, but something to note.

The second problem is a bug in the code snippet I provided earlier. I think your actionPerformed() method should be:

Code: Select all

public void actionPerformed(ActionEvent e) {

    textArea.clearMarkAllHighlights();
    if (c.getDot()!=c.getMark()) {
       return;
    }

    try {
       int start = Utilities.getWordStart(textArea, c.getDot());
       int end = Utilities.getWordEnd(textArea, c.getDot());
       String word = textArea.getText(start, end-start+1); // May need to be just (end-start), not sure
       textArea.markAll(word, false, true, false);
    } catch (BadLocationException ble) {
       ble.printStackTrace();
    }

}


Note the bug was that the second parameter to JTextComponent.getText(int start, int len) is the length of the string to get, not the end offset. Sorry about that. This was causing a "mark all" highlight of longer and longer length, depending on how far down in the document you placed the caret.

You'll also probably want to call setMarkAllHighlightColor() and set it to what you're currently using for your mark occurrences color to keep your color scheme as you'd expect.

Hope this helps!

[Vicne]

I believe the darker yellow colored region is the default "mark all" color. I think the problem here is twofold. First, you still have the default mark occurrences functionality enabled, which you don't want to do since you're providing your own substitute functionality with MarkAllOccurrencesSupport. Not really a problem, but something to note.

Oh, yes, indeed, I had forgotten green was not the default for highlights. Sorry.
I disabled the default highlighting and i now only get the new one.

The second problem is a bug in the code snippet I provided earlier.
Note the bug was that the second parameter to JTextComponent.getText(int start, int len) is the length of the string to get, not the end offset.

I see. No problem.
By the way, the end-start+1 is correct, but there is a "Caret c = textArea.getCaret();" missing at the beginning of course. Not a big deal.

Hope this helps!

Definitely. I'm getting close (errr, I should say you are getting close )
But there's still a glitch

The highlights work, but every time the timer fires (every second), it brings back the "caret" line in the view. In other words, if you have a 200 lines text shown in a 100-line view (so only half of it is visible) and line 1 is currently highlighted, if you try to scroll down to see the second half of the text, the text will jump back to the start, which is really annoying

I think this is due to markAll() fiddling with setCaretPosition() to search for occurrences, causing "state changed" events to be fired on the caret, which in turn cause the line highlighter to be brought in view.

Does it make sense ? Is there a simple way to avoid this ? Having a one-shot delay at each caret position change instead of a repeating timer maybe ?

Edit : now wait, it doesn't repeat. I guess there is something else in my code refreshing the view regularly that interferes with the setCaretPosition() in markAll()... I'm having a look.

Kind regards,

Vicne

[Vicne]

I guess there is something else in my code refreshing the view regularly that interferes with the setCaretPosition() in markAll()... I'm having a look.

OK. Doesn't look like it's linked to my other code in the end.
I think we have a loop effect: we manually move the caret to a given place, the updateCaret() listener method is called and restarts the timer. After it fires, it calls markAll(), which calls setCaretPosition(), which fires a state change... ant the updateCaret() listener is called again.
So we have a neverending update at the rate of one call every <delay>

I admit I don't see a way to solve this apart from rewriting markAll()...

What's your feeling ?

Kind regards,

Vicne

[robert]

Yes, looks like you're right. See the implementation of RTextArea#find(). It's using SearchEngine.find() to find all locations of the selected word; that method moves the caret to select the next match, so markAll() does one last setCaretPosition() after marking everything to move the caret back to its original position. And each caret change resets the timer.

Maybe as a workaround, in your callback, disable the support's listener before calling markAll() and re-add it afterwards? I admit that's quite a terrible hack, but I think it should work. The ultimate solution would likely be to move markAll() into SearchEngine and have it not move the caret around.