Solved [x] Close button in keymapping dialogue saves values for DX mappings instead of just closing the dialogue without saving
-
Version
4.37.3 / Falcon BMS Launcher 2.4.0 (x64) Vanilla InstallationBuild:
1329Detailed Description:
The “Assign Keys” dialogue for a specific mapping (double click in cell of the controller column) has two close functions. A) “save” in the lower right and B) “[+] close” in the upper right. Closing the dialogue with “[+] close” saves any changes made to the currently selected DX mapping.Launcher for 4.37.2 “[+] close” behaved like a “cancel” button here, i.e. no changes where made to the currently selected DX mapping.
Reproducibility Procedure
- open Flacon BMS Launcher 2.4.0
- click KEYMAPPING
- double click on any existend mapping with a DX mapping
- clear DX mapping
- close dialogue with “[+] close” in upper right corner
The DX Mapping has been removed.This issue may result in accidentially remapping existend mappings when done in the following way:
- open Flacon BMS Launcher 2.4.0
- click KEYMAPPING
- double click on any mapping
- ADD an already mapped DX key
- close dialogue with “[+] close” in upper right corner
The existing DX mapping gets removed and the new DX mapping gets saved
This weird behaviour is does not apply to Key mappings., It only happens for DX mappings.
Expected Behavior:
“[+] close” is expected to work as a cancel function for DX mapping changes like it is for Key mapping changes. -
@airtex2019
Gave AL pre-release v2.4.1.3 (commit a30d3ab) a shot:- behavior of Cancel / Close button is fixed from my pov
- Red warning text much appreciated
-
@r00t bug noted … thanks for the excellent bug report by the way – especially the note about key vs button behavior. probably saved me an hour of investigation.
-
Thank you all for investing countless hours that must have gone into the project over the years!
I was wondering if the modal window could be enhanced with a red-lined hint if key (or keys) already mapped.
Quick and srsly very dirty:
This may open yet another can of worms if you‘d have to name the current mapping in the message, space is limited in the current modal.
As mappings are 1:n, referring to the above example the text would be a csv list of already mapped stuff like „Foo, Bar, Foobar are already mapped“
Having a more advanced output naming new AND current mapping like:
„Foo is already mapped to Bar“ would involve scrollable lists to get all the information into the UI and possibly break tons of things.
Note:
While warnings could pop-up on pressing SAVE with a confirm or cancel option, I‘m not a huge fan of this concept for things that may happen in bulk. 25 additional clicks for remapping 25 buttons already mapped is not the best user experience IMHO :). But at the end of the day it depends on which data is available at which dialogue state - and if this suggestion makes sense at allDidn’t find any suggestions on how to properly make a „Feature Request“ so I posted it here because you are at the modal to fix the bug anyway and it’s kind of related to the topic :).
-
@r00t agree definitely already on my todo list, is to make it more clear when you’re (accidentally or purposefully) changing a button or key
of course a prereq first step for that is to actually make the ‘cancel’ button cancel … I see the bug in the code, will fix
-
@airtex2019
Gave AL pre-release v2.4.1.3 (commit a30d3ab) a shot:- behavior of Cancel / Close button is fixed from my pov
- Red warning text much appreciated
-
@r00t it was a very good UX suggestion – thanks for the nudge!
-