Re: SQL Macros in QueryTool.

Krzysztof Śmigrodzki wrote:
> Look'n'feel question. How should it look like?
> List with three column:
> - predefined names of keys on the left,
> - title field in middle
> - longer query input field on the right.
> (Above version would be similar to MS SQL Query Analyzer).
>
> Or maybe something more complicated?
> Vertical list (key, title) on the left, with arrow button to move
> position up and down. On the right two single line input fields (key,
> title) and multi-line text input for query?

I'd model it on the query favourites design. Have a dialog containing a
two column listctrl of keys and title, and then Add/Edit and Clear
buttons. The clear button would remove the selected macro, and the
Add/Edit button would open another simple dialog with a single line text
box for the title, and a multiline for the macro code (perhaps also with
a 'copy current/selected text from query tool' button).

> Any idea how to create the following functionality in wx:
> - first, one presses button ("choose shortcut")
> - then one inputs key combination
> - after key-up, key combination description (ex. "Ctrl-F1") is written
> into text field.

Well you'd create an OnKeyUp event and handler that would take the
keycode from the event object, and use ShiftDown(), ControlDown() etc.
to check the modifier keys.

But I wouldn't do it that way, because the user probably has too much of
a chance of selecting an invalid combination (because it's used for
something else for example). I'd pre-populate the listctrl with the
allowable combinations - we'd need to pick a range that doesn't conflict
with anything that's already used on any of our platforms. Hopefully we
can allow Ctrl-F1 -> Ctrl-F12 without interfering with anything, and
maybe the Alt versions as well.

>> Hmm, I'm not so sure about that. As someone who admin'ed quite a few
>> databases at once in a previous life, it seems to me that per database
>> or even per server macros could be quite confusing. I wonder if we
>> could have macro 'sets' that weren't necessarily tied to a specific
>> database or server, but could be selected independently.
>
> I've got different perspective:
> different databases, different queries to achieve the same result.

Well my databases were largely different. With sets you can easily
accomodate completely diverse databases, or users who might have live,
test and training databases for each of three or four applications. For
them, each set would correspond to an application.

>> Oh, and just so you are aware - we've gone into feature freeze now for
>> the upcoming release, so whilst you're free to develop (and we'll be
>> happy to help you), no patches will be committed to SVN until after
>> we've branched 1.8.
>
> So when will you branch?

Good question. We need to release no more than a couple of weeks before
PostgreSQL, but absolutely no later than with PostgreSQL. Unfortunately
that means it's all a bit of a guessing game at this point. I think it's
fairly certain to be a couple of months or more though.

If it becomes too much of an issue we can look at branching early (but
still releasing later). That might work, but isn't something we've done
before.

Regards, Dave.