Assistant v4 Feedback - first impressions

Good stuff, this!

First impressions are positive. No bugs found yet, but a couple of usability tweaks would help:

1. Add configuration for coding style - we work using spaces (never tab characters), and only two per indent. Code snippets etc. supplied by Assistant need to be fiddled after the fact - quite tiresome if it's a big block of code. Don't need to get too carried away here - just whether or not to use tabs, and how deeply to indent. I don't really want to have to edit each and every template etc., one global setting should do it.
2. A global ON/OFF hotkey would be really useful. When I'm working deep in the guts of something and Assistant keeps upper-casing every use of common words like FOR and AND, it gets rather tiresome - especially when I'm commenting/documenting somewhere. Fumbling for the mouse and looking for a tiny icon to right-click so I can find Suspend All really disturbs the workflow and annoys. Assist me, stop getting in my way.

This is NOT a complaint! But you were looking for feedback, so there it is. More to follow as I use it more.

Thanks. Your feedback is much appreciated. I'll pass it along.

By the way, can you elaborate a bit more on "keeps upper-casing every use of common words like FOR and AND" Which editor are you using in that case? Is that in comments? or some other place? Perhaps some tweak in the current config can help to avoid this issue and then you wouldn't need to worry about switching it on and off.

	kenpem wrote:
	1. Add configuration for coding style - we work using spaces (never tab characters), and only two per indent.

I second that -- we use 4 spaces per indent, never tabs.

Already in the queue, enhancement #2077. It is not yet know in which version this will be implemented

	SysOp wrote:
	Thanks. Your feedback is much appreciated. I'll pass it along. By the way, can you elaborate a bit more on "keeps upper-casing every use of common words like FOR and AND" Which editor are you using in that case? Is that in comments? or some other place? Perhaps some tweak in the current config can help to avoid this issue and then you wouldn't need to worry about switching it on and off.

Sorry, I should have been a LOT more detailed in my report! My bad.

This occurred working in Toad for MySQL v3.1.1.642, running on Windows XP Pro SP3, connected to an OpenBSD 4.3 VM running MySQL 5.0.51. It happens just about anywhere I type within Toad - while entering data directly on the data grid, entering comment text in the Alter Table dialogue, naming columns & other objects, etc. It appears to be always trying to help Toad, no matter what the activity.

Thanks. It seems that the same edit class is used in recent versions of Toad in too many different places, not just for the editor. While SQL Assistant is not designed specifically for Toad, we do support Toad as one of pre-registered targets, and perhaps we should check latest Toad versions and tighten the filters so that SQL Assistant kicks in only where it is needed.

Here is what you can do to tune the settings. Open SQL Assistant Options. Locate your Toad version in Targets list. Expand Advanced properties group. In the Target Window Class property change the value from "WindowsForms%" to "WindowsForms10.Window.8.%" Save changes in options.

This change should make SQL Assistant target only the editor and will leave edit controls in the data grid, in extended properties and other places alone. I found out that that the same edit class is used for Table Description property in the Alter Table dialog, which I'm not yet sure how to eliminate, but that's the only place where the same window class is used. Everything else seems to work ok after the above-mentioned changes of the window class filter.

That certainly seemed to help - thanks!