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

Feed back the keypress code that was responsible for the 'close' even… #5513

Merged
merged 2 commits into from Jan 28, 2020
Merged

Feed back the keypress code that was responsible for the 'close' even… #5513

merged 2 commits into from Jan 28, 2020

Conversation

6pac
Copy link
Contributor

@6pac 6pac commented May 16, 2019

Feed back the keypress code that was responsible for the 'close' event as part of the event parameters. This is a non-breaking enhancement that doesn't affect any existing behaviour.

@stale
Copy link

stale bot commented Jul 15, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status: stale label Jul 15, 2019
@6pac
Copy link
Contributor Author

6pac commented Jul 15, 2019

this would be really handy for a lot of use cases, folks! Very safe and small. Please consider.

@stale stale bot removed the status: stale label Jul 15, 2019
@stale
Copy link

stale bot commented Sep 13, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status: stale label Sep 13, 2019
@6pac
Copy link
Contributor Author

6pac commented Sep 13, 2019

bump

@stale stale bot removed the status: stale label Sep 13, 2019
@kevin-brown
Copy link
Member

Just realized I never reviewed this one.

Generally I'm okay with things like this being done (providing event context when we do things), but in the past we've done this by passing originalEvent pointing to the original event which caused this action. This would be compatible with what you're looking for (getting the triggered keypress from the close event) while also maintaining consistency

originalEvent: evt

originalEvent: evt,

originalEvent: evt,

@6pac
Copy link
Contributor Author

6pac commented Oct 14, 2019

OK, makes sense, changes made...

@kevin-brown
Copy link
Member

Thanks a bunch for making that change!

This PR has been accepted for the next release of Select2 (likely 4.0.12) and will be merged in the near future once the most recent release has stabilized.

@6pac
Copy link
Contributor Author

6pac commented Oct 14, 2019

Thanks, that's great!

@kevin-brown kevin-brown modified the milestones: 4.0.12, 4.0.13 Nov 6, 2019
@stale
Copy link

stale bot commented Jan 5, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status: stale label Jan 5, 2020
@6pac
Copy link
Contributor Author

6pac commented Jan 5, 2020

bump

@stale stale bot removed the status: stale label Jan 5, 2020
@kevin-brown kevin-brown merged commit 3b69d35 into select2:develop Jan 28, 2020
@joepetrakovich
Copy link
Contributor

This is a great start, but I think it would make sense to include the original event on all triggers of the close event.

This one only works if the select closes from that small set of keyboard commands, but if it's closed via things like selectOnClose or the many other calls to self.close or trigger('close'), the original event is missing.

This feature is nice because I can observe the tab or shift-tab key being pressed to close the dropdown, but it doesn't work if selectOnClose is enabled, and there is still no way to see if the enter key was pressed. Also, if the user selects the original value that was already selected, the close event is trigger but the original event is missing.

@6pac
Copy link
Contributor Author

6pac commented Jan 30, 2020

I was simply using this for keyboard navigation in a grid. For example, I need to know if it was closed with an Enter (focus remains or go to next control), Tab (go to next control) or Shift-Tab (go to last control).

@joepetrakovich
Copy link
Contributor

joepetrakovich commented Jan 30, 2020 via email

@kevin-brown
Copy link
Member

As always, we encourage further pull requests that expand this functionality out to more use cases.

@6pac
Copy link
Contributor Author

6pac commented Jan 30, 2020

@joepetrakovich which grid? perhaps we should establish a simple test page? I'm using SlickGrid, but I don't suppose the grid really matters that much.

@joepetrakovich
Copy link
Contributor

@6pac yeah it probably doesn't matter. I'm using DevExpress's ASPxGridView in batch edit mode (https://demos.devexpress.com/ASPxGridViewDemos/GridEditing/BatchEditing.aspx).

They have their own built in autocomplete dropdown but it's slow and clunky compared to Select2. If you add custom controls into the grid cells you have to re-implement the keyboard navigation. This commit made it a lot easier but like I said since the keypress event is lost in most other actions on the dropdown, I haven't gotten it fully fleshed out without weird non-compliant hacks.

I may try my hand at a pull request.

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

Successfully merging this pull request may close these issues.

None yet

3 participants