MySQL Bugs: #11461: Column width change each time you requery or refresh

Bug #11461	Column width change each time you requery or refresh
Submitted:	20 Jun 2005 14:48	Modified:	29 Jan 2018 11:03
Reporter:	Kai Sautter (Basic Quality Contributor)	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	MySQL Query Browser	Severity:	S4 (Feature request)
Version:	1.2.12	OS:	Windows (Winsows XP (SP2))
Assigned to:		CPU Architecture:	Any
Tags:	Contribution, qc

Description:
Each time you re-execute or refresh a query, the column widths are set back to the default width. If you have changed the column width for better visibility of data, these changes get lost.

How to repeat:
(1) Execute a query
(2) Change the width of at least one column
(3) Either requery the same query or press "Refresh"

Suggested fix:
I would not necessarily expect Query Browser to keep the column widths when requerying the same table (though it would be handy), but it would be very helpful, if the (changed) column widths would be kept when refreshing a query.

Bump? Version 1.2.11 and still not a feature :(

As long as the columns listed in the query remain unchanged in the same Resultset Tab, then I think it's reasonable to expect QB to remember the column widths.

Every Microsoft products are able to memorize column width or to auto adjust by double clicking, I don't understand why Mysql-query-browser couldn't ?

Many thanks for writing a feature request.

Verified as described by using Query Browser version 1.2.12

Bug #35290 and bug #18574 are duplicates of this bug here.

Bug #11148 and bug #11636 are duplicates of this bug here.

Suggested implementation

Attachment: mysql-qb-diff (application/octet-stream, text), 1.74 KiB.

I just added a suggested implementation for the "automatic" column width
feature.  It behaves the way it used to unless the user sets the max
width to 0 in the preferences dialog.

It uses the value_length from the rows entry for each resultset column.
It's possible that this is too wide for 16-bit character contents.

For BLOBs, it always uses a value of 1.  This at least works with JPEG
images which I tested as an example for BLOBs.

Suggested implementation, UTF-8 issues fixed now

Attachment: mysql-qb-diff (application/octet-stream, text), 1.89 KiB.

OK, I found that there's really been an UTF-8 string length issue in my
previous patch, and fixed it in the second patch.  However, for reasons
I didn't investigate, CellRendererBlob::get_size_vfunc() (File
MGCellRendererBlob.cc) thinks the resulting space is too small now for
displaying an international text, and adds ellipsis dots for it even
though the string obviously fits (i.e., it is displayed in full).  This
bug must have been there before, but it was apparently rarely hit since
it only happened in situations where a string with non-ASCII characters
was incidentally exactly the size of the max_blob_length user preference.

Yet another update: correctly account for multiline strings where only the first line is displayed in the table view

Attachment: mysql-qb-diff (application/octet-stream, text), 2.13 KiB.

Many thanks for providing a patch. We will look what we can do with it.

Bug #48198 was marked as a duplicate of this one.

Issue has been reported for a product that no longer exists.