I have over 200 databases, and it is becoming increasingly cumbersome to choose one from the DB drop-down in SqlYog. The drop-down only shows 14 DBs at a time, which even on the lowest of resolution screens, doesnt maximize the number of DBs that could be viewable.

Please make it so the drop-down extends all the way to the bottom of the screen.

I think we increased the size of this dropdown not so long time ago (about 9 month if I remember correctly).

I also think there are some limitations with the Scintilla component that causes this linitation.
When we increased it was because it became possible after a new Scintilla version became available.
I also think a more recent one is now available again.

But I cannot tell exact details before beginning of next week (due to the weekend).


BTW: You may click a database in the Object Browser as well.

I can live with that.

But c'mon now Peter, how many more years until there is a 'show table data in text' option? Didnt Ritesh mention he upped the priority on that like 2 years ago? Such a simple core request, that would make life for coders so much easier, yet all these extra fluff features keep being added.

And how hard can it be to fix the existing 'Show Results In Text' preference to be persistant, similar to the options like word wrapping and autocomplete? I launch an instance of SqlYog maybe 15 times per workday, it gets really old to have to remember to click Ctrl+L each time.

Sorry for the late reply.

For internal workflow reasons we will have to release 6.2 first. After 6.2 release (estimated 3-4 weeks) we will add this with priority.

I see that 6.5 has been released (im guessing this what you meant by 6.2?) after 4 months -- So, can we finally add the 'show table data in text' option (and allow this preference to be saved) "with priority"???

Since we started using UTF8 internally in 6.0 we have a problem.

The problem is that currently we have no way to retrieve in length of a string in CHARCTERS, only as BYTES from the Scintilla editor used for text display. Our own GRID code can handle it however. As a consequence the strings

ABCabcn
Àbcàbcn
ÆØÅæøån
ABCabcñ

.. etc. do not align properly in text mode as UTF8 characters can be 1, 2, 3 bytes long

This already affects OBJECTS tab, RESULT tab in text mode ext. This I think we can live with - though I also think we should now focus on it. But in DATA tab we cannot live with it. So this will have to be solved first.

correction: we only use scintilla in the editor. But problem is basically still the same: to dientify the characterlength of a utf8 string (and not the byte length) without destroying performance. I think we have an idea about it now. But it requires some testing.

Today was Holiday for most Webyoggers.

Um... that is the lamest excuse I have ever heard. first of all, i never have any of those weird characters anywhere in my databases, so it is non-applicable. Second of all, how hard can it be to just produce the output exactly as if the mysql command line client produces it. It's JUST TEXT. Give me one good reason the DATA tab cannot live with it if the results tab can? The results tab, by default, uses your GRID code. then with a preference, it switches to text mode. There is no reason the DATA tab should not be able to toggle back and forth in the exact same manner So now what, its it going to take three more years to figure out?

Have you considered anything else besides scintilla? My understanding is that Scintilla is a code editor, which is way overkill for simple textual display of result or table data. Notepad2 would be perfect: http://www.flos-freeware.ch/notepad2.html

Another major annoyance of the Scintilla editor is that it does not work correctly with mouse wheel acceleration. When I try scrolling with my Logitech MX Revolution, its unbearably slow and it has no idea when to stop scrolling.

I told it was a mistake what I wrote first. We use Scintilla in the Editor tab - and for simple text display (in RESULTs/text, OBJECTs etc.) we don't - this is simpe code of our own. We need a full featured code editor for the Query tab (without it we would never be able to support autocomplete etc.)

Is the scroll issue you are reporting an issue with the editor, the GRIDS or the text tabs?

We have no plans to change scintilla with something else. I do not know if Notepad2 is fit (I once had a very old version that did not support unicode - so this version is definitely not). Also want a tool that depends on the Win32 API only (no foundation classes etc.).

Except for that I think I personally should not comment more on those code internals.


Due to MySQL UC this week don't expect more feedback this week on this!

My fault, I should have clarified -- it's just when scrolling in the Results tab in Text mode that the scrolling issue occurs.

Scrolling in the Query Editor, History tab, and Objects Tab works nicely! So, if those use scintilla, it works great, dont change a thing!!! Scrolling in Data or Results tab in GRID mode is very slow, but constant -- it does not know how to to do accelerated scrolling but it does know when to stop.

Unfortunately the mode I use most, Results tab in Text mode, behaves erratically. So, why not use scintilla for Results tab in Text, and also for the new Data tab in Text feature that will be released any day now?

Hope the MySQL UC went well for you. So, to clarify, is the Scintilla or the "code of your own" which is the holdup for the table results in text feature? If "code of your own" is the issue, why not make the result and table text use scintilla also -- it would most likely also fix the scrolling issue.

sorry, I forgot to reply to this.


We cannot reproduce the problems with scrolling. It scrolls fine for us (also with huge result sets) with both the window/tab scrollbar and mouse scrollwheel.

Can you point to somehow to reproduce this? BLOBs or other types of data, # of rows in the result, # of columns ... anything? If you have more systems is this reproducable on every system ...

It this is a mouse scrollbar (only) issue, does your mouse use a special driver and not the MS/Windows default driver (like a Logitech driver)??

Yes, it is the Logitech driver (MX Revolution), which works perfectly in the Query editor, Objects tab, History tab. Really the only way i can think to reproduce would be to use a logitech mouse, which I daresay a heck of alot of folks do. Perhaps I can do a screen recording video to illustrate. Really though, its a minor annoyance -- while it would be nice to have smooth Logitech scrolling, my main reason for suggesting the switch from custom code to Scintilla is so the table data in text feature can be done ASAP, after three years of delays.

Ok -- then I think we will need to check against some Logitech hardware and driver.

First try here with a Logitech mouse did not reproduce the problem.

Can you please tell the exact mouse model and the driver version?
Did you check if there is an updated driver here: http://www.logitech.com/index.cfm/support_...oads/downloads/

I assume you are using a Logitech driver to support additional 'smart' features of the mouse. Anyway the basic features of the mouse may work with the native mouse driver of the OS. Could you try?

the exact model is the MX Revolution. The driver version is the lates version of SetPoint, 4.24.99

the basic features do work, yes. the issue occurs when using the scroll wheel when there are thousands of records in the text results. if you flick the wheel down to scroll, and then stop the wheel, the buffer keeps scrolling down on its own when it shouldn't. if i copy those thousands of text rows and paste them into the query editor (just for the purposes of testing scrolling there in comparison), the query editor does not exhibit such bad behavior, scrolling down is fast and it stops as it should when you stop the wheel.

Our test case is 500,000+ rows ... and it works fine for us with every hardware/driver combination we have tried.

But let us try if we can use this additonal information somehow!