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

Allow entering custom display formats #573

Closed
MKleusberg opened this issue Apr 21, 2016 · 5 comments
Closed

Allow entering custom display formats #573

MKleusberg opened this issue Apr 21, 2016 · 5 comments
Labels
enhancement Feature requests.

Comments

@MKleusberg
Copy link
Member

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:

  1. If the user types in some invalid code we'd get a syntax error. Not sure how we'd react there but we definitely don't display a proper error message.
  2. The user could type in some code that generates more than one column. This one is tricky because it doesn't produce a syntax error but would cause a lot of confusion throughout the application. So by some means we'd have to detect this case and prohibit it.
@jungle-boogie
Copy link
Contributor

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".

@justinclift
Copy link
Member

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". 😄

@justinclift justinclift added the enhancement Feature requests. label Apr 22, 2016
@mgrojo
Copy link
Member

mgrojo commented Nov 6, 2017

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.

@justinclift
Copy link
Member

@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). 😄

mgrojo added a commit that referenced this issue Jan 27, 2019
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
mgrojo added a commit that referenced this issue Feb 10, 2019
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
mgrojo added a commit that referenced this issue Feb 15, 2019
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
@mgrojo
Copy link
Member

mgrojo commented Feb 15, 2019

Closing this, as PR #1720 is already merged.

@mgrojo mgrojo closed this as completed Feb 15, 2019
@mgrojo mgrojo added this to the 3.12.0 - Future release milestone Feb 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests.
Projects
None yet
Development

No branches or pull requests

4 participants