Re: SQL Macros in QueryTool.
От | Dave Page |
---|---|
Тема | Re: SQL Macros in QueryTool. |
Дата | |
Msg-id | 46811EFE.7090304@postgresql.org обсуждение исходный текст |
Ответ на | Re: SQL Macros in QueryTool. (Krzysztof Śmigrodzki <ksmigrod@gmail.com>) |
Список | pgadmin-hackers |
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.
В списке pgadmin-hackers по дате отправления: