Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update InPlaceEditView.java #3814

Closed
wants to merge 1 commit into from

Conversation

ImmediandoSrl
Copy link
Contributor

add implementation for unknown listener

add implementation for unknown listener
@shai-almog shai-almog mentioned this pull request Jun 14, 2024
@shai-almog
Copy link
Collaborator

Unknown event doesn't make sense to me. If there's an important event we need to deal with it correctly, not throw it into the miscellaneous pile. That might seem like a reasonable hack when we start but pretty soon the miscellaneous pile will become the largest and people will depend on behavior that isn't cross platform.

The escape change is fine and makes sense. But isn't it effectively the same action as back?

Why not use the same switch as that?

@ImmediandoSrl
Copy link
Contributor Author

i would like to intercept phyisical key ESC so when press i call a function that copy values from previous rilevation (price, facing) to new one.
doing unknown event as i do i can intercept with unknownlistener the keyCode of key pressed so overriding TextField i can switch to keyEvent and do what i prefer.

textfield.setUnknownListener(new ActionListener() {
public void actionPerformed(ActionEvent evt) {
switch(evt.getKeyEvent()) {
case 111: //Do something
case .... :
}
});

@ImmediandoSrl
Copy link
Contributor Author

with donelistener I no longer have references to the code of the pressed key

@shai-almog
Copy link
Collaborator

A key event should arrive anyway in key events. This is a special case of native editing where the text is edited by the OS. You want to send something back to the Java layer which is currently not responsible for anything (since we're in editing mode). This means moving to a different thread and in the meantime the native OS might do other things (like add additional text). You're setting yourself up to disaster and this is Android only anyway.

The question is what is the "Do something"?

By doing it this way you're creating fragile unportable code. Might as well implement a generic solution at the implementation layer that works correctly.

It might be possible to add the keycode that triggered the done event to the ActionEvent that is sent.

E.g. this method can't be removed since it's public. But you can add another one that accepts an ActionEvent and pass your own action event from here.

I'm not sure if that's the best option since I don't have all the information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants