Some MouseEvent behaviors cannot be safely overridden because hooks for them do not yet exist #357
Comments
MichelMunoz
changed the title
|
If I'm understanding you correctly, this is what happens...?
|
|
Additionally, does this correlate with #321 ? |
|
Yeah i suppose it is correlated to #321
I'll try to do a screen capture tonight. |
|
What you described is what I meant, but your rephrasing communicates it much better than my original one 😃 |
|
There; I have done a screen capture showing the thing. You'll notice I've numbered the calls to hit.
|
|
@MichelMunoz I tried reproducing the bug using the 7-M2 release and wasn't able to. After I release the mouse (even outside the JavaFX window), it stops the emission. Could you show us a small stand-alone program of your code? I wonder if there's something else going on that causes this to occur, such as you overriding some of the default behavior that runs package-private code. Perhaps your issue arises because that code isn't executed. |
|
Ok, I'll try to do that this week end 2016-10-07 6:55 GMT+02:00 JordanMartinez [email protected]:
|
|
Let's also compare the environments. @MichelMunoz is apparently on Windows on JDK 1.8.0_91. |
|
Okay, I've done it, some explanations first.... The use case : I have a pseudo console with a prompt, I do a selection via drag ; end of drag automatically copies the selection to the clipboard (like some unix consoles), and the reposition the cursor at a valid position (ie. at minimum after the "prompt"). In the attached code you will see that you can trigger the bug by having the drag going outside the component in any direction (top, bottom, left, right, same problem) ; but if selection gesture stays within the component, no problemo. I've joined the gradle build file (3+) to the sources and made the source as simple as possible |
|
An even more minimalist version, without prompt mechanism or copy, same gradle as previous reply. |
|
Aye, it is an issue with overriding the default behavior. |
|
I'm posting @MichelMunoz's code here so one doesn't need to download it, and then I'll surround the issue with comment indicators ("/////"): import static org.fxmisc.wellbehaved.event.EventPattern.eventType;
import static org.fxmisc.wellbehaved.event.InputMap.consume;
import static org.fxmisc.wellbehaved.event.InputMap.sequence;
import org.fxmisc.richtext.CharacterHit;
import org.fxmisc.richtext.StyledTextArea;
import org.fxmisc.wellbehaved.event.Nodes;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.input.MouseButton;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;
public class RTFxBug2 extends Application {
@Override
public void start(Stage primaryStage) {
StyleClassedTextAreaExt2 inputArea = new StyleClassedTextAreaExt2();
Nodes.addInputMap(inputArea, sequence(
/////////////// OVERRIDES DEFAULT BEHAVIOR ////////////////
consume(eventType(MouseEvent.MOUSE_RELEASED),
// the following line prevents `autoscrollTo.set(null)`,
// which causes your issue
e-> inputArea.mouseReleased(e))
/////////////// OVERRIDES DEFAULT BEHAVIOR ////////////////
));
BorderPane root = new BorderPane();
root.setCenter(inputArea);
Scene scene = new Scene(root, 300, 250);
primaryStage.setTitle("Bug #357");
primaryStage.setScene(scene);
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
class StyleClassedTextAreaExt2 extends StyledTextArea<String, String> {
public StyleClassedTextAreaExt2() {
super("", (tf,s) -> {}, "", (te, s) -> {}, true);
}
int counter = 0;
@Override
public CharacterHit hit(double x, double y) {
CharacterHit hit = super.hit(x, y);
System.out.println("HIT call #" + counter++);
return hit;
}
///////////// To Achieve the same thing, you'll need to use a hook /////////
public void mouseReleased(MouseEvent e) {
if (e.getButton() == MouseButton.PRIMARY) {
moveTo(0, SelectionPolicy.CLEAR);
}
}
}You might already be able to use the hook we've implemented. See |
|
I just tested the I think the real issue here is that STA's mouse behavior should not be overridden. Rather, there needs to be more hooks that can be overridden for special circumstances like this. |
|
Ok, so, I guess in my case a new hook "onSelectionDone" that would be called in the "case NO_DRAG:" of your link would work, no ? |
Yes. As an alternative for right now until this gets fixed, you might be able to use
We implemented the area.setOnSelectionDrop(e -> {}); |
JordanMartinez
changed the title
|
Closed by #468 |
First, thanks for this very promising component.
Now, the observed behavior. In my code (a console widget) I wanted to reposition the cursor after a text selection was made (on mouse released, using moveTo), it worked well except when the drag ended out of the component area. Annoyed by the thing, I digged, and ended finding that it was somehow linked to hit computation and drag code ; when the drag (of selection) ends within the component all is fine, but when the drag ends outside the component the hit methods is called infinitelly and the moveTo doesnt work as expected.
Version used : the last one (7-M2), but the behavior was observed pre-7.
To reproduce/observe the problem, a "crude" approach :
The observed stacks of the continuous calls are :
P.S.
If it is of any value, one point I observed in the code of your component while digging the problem :
The text was updated successfully, but these errors were encountered: