-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Allow entering custom display formats #573
Comments
I first encountered the custom option when selecting one of the other available options (hex, octal, round number, etc) on a colum, and then going back to "edit display format". I noticed my selection was not what I previously selected (hex, octal, round number, etc), but rather it was "custom". |
That's a good point, I've noticed that too. The label for the chosen option should probably be kept, instead of switching to "custom". 😄 |
I think, most of the custom formats, that the users would want to add, would be a call to the sfrtime, printf or similar format functions for the column (one example is in #1213). What if we only allow custom formats of this form, that could be easily validated using regexps? It would be at least an improvement over the current situation. |
@mgrojo That sounds like a pretty decent concept. It also doesn't sound super complex to get working, though it could turn out to be trickier than expected (unsure though). 😄 |
Allow user to define their own display formats. The SQL code is editable and the combo box changes automatically to custom if the user edits one of the predefined formats. The display format (either custom or predefined) is validated with a regex so at least it is a function containing the column name. Note that this might be fooled in some way, but the users should know what they're doing. See issue #573
Added a new callback for executeSQL following the model of sqlite3_exec. Using this, the number of columns is got from the query execution. If it is not one, the custom display format is rejected. The regexp is also narrowed to accept only SQL functions applied to the column name (it now matches the entire string). See issue #573
Allow user to define their own display formats. The SQL code is editable and the combo box changes automatically to custom if the user edits one of the predefined formats. The display format (either custom or predefined) is validated with a case-insensitive regex so at least it contains a function applied to the column name. Added a new callback for executeSQL following the model of sqlite3_exec. Using this, the number of columns is got from a checking query execution. If it is not one, the custom display format is also rejected. Note that these validations might still be fooled in some unforeseen way, but the users should know what they're doing. See issue #573
Closing this, as PR #1720 is already merged. |
See issue #569. It would be nice to be able to enter custom display formats in the Edit Display format dialog when the format you require isn't part of the list. Bonus points for remembering custom display formats and having an option to give them names etc.
There are two problems here though. Both requiring us to add some more error checking code:
The text was updated successfully, but these errors were encountered: