In the edit dialog the clear button sets the data to
NULL, but because we check if the data has changed
before updating, we need to also check the NULL flag,
otherwise we can't tell NULL values from empty values.
See issue #220.
When not configured otherwise in the Preferences Dialog register a
SQLite function for performing the regular expression matching which
SQLite doesn't implement. This adds support for the REGEXP operator even
when no extension which implements this is loaded.
See issue #215.
Commit 9e4a6df changed the way fetchData() handles NULL values
so they could be seen by the user. However, the same change wasn't
added to DBBrowserDB::getRow().
Because both are called by the table model and we now add colors
to NULL fields, this caused a visible bug when adding a row with
not null column constraints.
See issue #214.
Make sure to include the problematic SQL statement in the error message
when an error occurs in DBBrowserDB::executeSQL().
Execute SQL statements via executeSQL() wherever possible instead of
manually invoking sqlite3_exec(). This simplifies the code a bit and
makes sure the improved error messages are used.
Add a new checkbox to the Preferences Dialog which allows the user to
fully disable automatic check for new versions instead of just ignoring
the last shown update message. This also prevents DB4S from performing
any HTTP requests.
See issues #173 and #208.
When browsing a table in the Browse Data tab of the main window you can
move the focus to the next cell by pressing the tab key. This commit
improves this behaviour by checking if the tab key has been while the
last cell of the last row is focused. If this is the case a new, empty row
is inserted automatically into the table.
See issue #209.
The sqlitetablemodel will need to access the color
setting for null fields. This breaks the tests if
the PreferencesDialog files are not linked to the
test executable.
When replacing placeholders, QString::arg() looks for
the sequence %n (where n is a number between 1 and 99).
As it turns out this sequence can also appear in SQL
queries and so they were being mistakenly replaced.
See issue #203.
Qt tries to determine the role of a menu item based on its text. If the
text is "Preferences" it guesses that that menu item opens the
preferences dialog. On MacOS X this means the menu item is moved from
the View menu to the application menu. However, for translations this
doesn't seem to work, so this commit sets the menu roles manually. At
least that's the idea - no idea if it works.
See issue #200.
Commit ae03113 broke the UI: the signal triggered when pressing
the button to change the default location and the tab order
had been lost.
See issue #197.
